Fresh installs now resolve the torch 2.11 trio (torch 2.11.0,
torchvision 0.26.0, torchaudio 2.11.0) everywhere the wheels exist,
verified by live index resolution for py3.11-3.13: Linux x86_64
(cpu, cu126, cu128, cu130, rocm7.1, rocm7.2), Linux aarch64 (cpu,
cu130), Windows x86_64 (cpu, cu126, cu128, cu130; triton-windows<3.7
resolves 3.6.0.post26, the 2.11 pairing) and macOS arm64. Existing
installs are unaffected: the release preservation on both installers
keeps the installed torch on re-runs (verified end to end against the
live cpu index: a seeded 2.10.0 venv stays 2.10.0 with paired 0.25/2.10
companions while a fresh venv resolves the 2.11 trio).
- install.sh: the supported range is centralized in _TORCH_CEILING /
_TORCHVISION_CEILING / _TORCHAUDIO_CEILING and composed into the
default constraints, so the next bump (torch 2.12) is a three-line
change. The now-redundant cu* widen arm and custom-pin companion
block collapse into the default; the curated ROCm >=2.11 floors stay
literal.
- install.ps1: the hoisted default trio, the CUDA flavor repair and the
ROCm CPU fallback all use the <2.12 trio (the leaf gate collapsed
since cu and non-cu now share the range).
- setup.ps1: the unknown-leaf pinned CUDA trio widens to <2.12,
matching the pinned cpu path.
Deliberately NOT widened: rocm6.4 (tops at torch 2.9.1) and rocm7.0
(2.10.0) by index content; macOS x86_64 (no >=2.4 wheels, stays
no-torch); the AMD per-arch repo.amd.com curated bounds for arches
outside the 2.11 allowlist.
Constraint suites updated to the ceiling scheme; parity suites updated
to the widened trio. All sh, ps1 and pytest installer suites pass (the
host-defaults suite and the tokenizers negative-control are known
pre-existing failures).
3f79b5e53d