[Getting Started Page] Modify published_versions.json, releases.json and quick-start-module.js - #2130
Merged
Merged
Conversation
✅ Deploy Preview for pytorch-dot-org-preview ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
pytorchbot
force-pushed
the
create-pull-request/update-quick-start
branch
from
August 7, 2026 18:57
f5b6243 to
8726330
Compare
Contributor
|
@atalman Let's merge this PR once the nightly torchvision wheels are published for rocm7.14. |
Contributor
|
@atalman ping |
pytorchbot
force-pushed
the
create-pull-request/update-quick-start
branch
from
August 10, 2026 18:58
8726330 to
ded4600
Compare
Contributor
|
torchvision wheels for rocm7.14 are also being published now: https://download.pytorch.org/whl/nightly/rocm7.14/torchvision/ |
atalman
added a commit
to pytorch/test-infra
that referenced
this pull request
Aug 11, 2026
`update-quick-start-module.yml` in pytorch/pytorch.github.io calls `generate_binary_build_matrix.yml@main` with `getting-started: true` for linux/windows/macos-arm64 on the nightly and release channels, and publishes the result as the pytorch.org install selector. Because 13.4 is in `CUDA_ARCHES_DICT["nightly"]`, that bot has started adding a `cu134` option — see pytorch/pytorch.github.io#2130, which introduces: ``` pip3 install --pre torch torchvision --index-url https://download.pytorch.org/whl/nightly/cu134 ``` 13.4 is built and validated, but it is not ready to be offered to users, so this gates it out of **the getting-started matrix only**. ## Approach `initialize_globals` already accepted a `getting_started` argument that was never used — this gives it a purpose. The filter follows the existing `CUDA_ARCHES_NO_WINDOWS` convention immediately above it: ```python CUDA_ARCHES_NO_GETTING_STARTED = ["13.4"] ``` To re-enable 13.4 on the page later, drop it from that list — no other change needed. `CUDA_AARCH64_ARCHES` is deliberately untouched: the getting-started workflow never requests `linux-aarch64`, and that list is a module constant with no per-channel dict behind it, so filtering it in place would leak into later calls in the same process. ## Test plan - `python -m tools.tests.test_generate_binary_build_matrix` — 11 tests pass. - `--update-reference-files` — no asset changes. - Getting-started matrix (`--getting-started true`), `cu134` entry count before -> after, across all six jobs the quick-start workflow runs: | os | channel | before | after | | --- | --- | --- | --- | | linux | nightly | **2** | **0** | | linux | release | 0 | 0 | | windows | nightly / release | 0 | 0 | | macos-arm64 | nightly / release | 0 | 0 | The two linux/nightly entries are the wheel + libtorch options #2130 was adding. Windows was already 0 via `CUDA_ARCHES_NO_WINDOWS`. - **Non**-getting-started matrices are byte-identical (md5) for `{linux, linux-aarch64, windows, macos-arm64}` x `{nightly, test, release}` — builds and binary validation are unaffected. - Verified the filter does not leak across calls: after a `getting_started=True` call, a subsequent default call still sees `['12.6', '13.0', '13.2', '13.4']`. Authored with the assistance of Claude Code.
pytorchbot
force-pushed
the
create-pull-request/update-quick-start
branch
from
August 11, 2026 22:29
ded4600 to
3c7da23
Compare
atalman
approved these changes
Aug 11, 2026
atalman
added a commit
to pytorch/test-infra
that referenced
this pull request
Aug 11, 2026
pytorch.org/get-started/locally/ advertises **ROCm 7.2** as the nightly
ROCm, even though 7.14 is current.
### Why
The getting-started page renders exactly one ROCm choice.
`pytorch.github.io`'s `gen_quick_start_module.py` picks which one with a
plain `max()` over version *strings*:
```python
acc_arch_ver_map[chan]["rocm5.x"] = ("rocm", max(rocm_ver_list.values()))
```
```
>>> "7.14" > "7.2"
False # '1' < '2' at the third character
>>> max({"7.2", "7.14"})
'7.2'
```
So once `ROCM_ARCHES_DICT["nightly"]` became `["7.2", "7.14"]`, the page
started showing the older one. This never bit before because ROCm minors
were single-digit; 7.14 is the first two-digit minor.
That is also why
[pytorch.github.io#2130](pytorch/pytorch.github.io#2130)
landed touching only `releases.json` and not `published_versions.json` —
the generator recomputed the same `rocm7.2` command it already had, so
there was no diff. Re-running or re-deploying it would not help.
### Fix
Send the page one ROCm version instead of two, chosen with a
version-aware key:
```python
if getting_started and channel == NIGHTLY:
ROCM_ARCHES = [max(ROCM_ARCHES, key=parse_version)]
```
Fixing it here rather than in the website's `max()` means the page
cannot pick wrong, because it is only ever offered one option.
### Scope
Deliberately narrow — `getting_started` **and** `nightly`:
| | rocm arches |
|---|---|
| nightly, getting-started | `['7.14']` |
| nightly, normal build matrix | `['7.2', '7.14']` unchanged |
| release, getting-started | `['7.1', '7.2']` unchanged |
| test, getting-started | `['7.2', '7.14']` unchanged |
**The binary build matrix is untouched** — nightly still builds every
ROCm in `ROCM_ARCHES_DICT`. None of the `tools/tests/assets/*.json`
snapshots use `--getting-started`, and all are byte-identical.
Verified end to end by replaying the website's own logic against the new
matrix:
```
getting-started=false rocm_ver_list={'rocm7.2': '7.2', 'rocm7.14': '7.14'}
website max() picks -> '7.2'
getting-started=true rocm_ver_list={'rocm7.14': '7.14'}
website max() picks -> '7.14'
```
### Still latent, not addressed here
The `release` channel getting-started matrix still ships two ROCm
versions (`7.1`, `7.2`). It happens to be correct today because `"7.2" >
"7.1"` as strings too — but it will break the same way the moment a
double-digit minor reaches release. Same one-line treatment applies
whenever you want it; left out to keep this scoped to the reported
problem.
### Test plan
```
$ python -m tools.tests.test_generate_binary_build_matrix
Ran 14 tests in 0.005s
OK
```
Three new tests: `parse_version` orders `7.14` above `7.2`; nightly
getting-started yields exactly one ROCm and it is the newest; nightly
normal builds still yield every ROCm (guards against this leaking into
the build matrix).
mypy, ruff format and usort clean.
Co-authored-by: Andrey Talman <atalman@users.noreply.github.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR is auto-generated. It updates Getting Started page