ROCm maintainers confirm PyTorch package mismatch issue mitigated, while stable-channel docs still list alpha versions

ROCm TheRock maintainer ScottTodd closed an issue involving the PyTorch release workflow on October 16, saying it had been fixed or mitigated while acknowledging that additional checks could be added at each release stage. The update confirmed the status of earlier patches; the changes had already landed in nightly builds in early October, so this does not establish that all existing stable packages have been re-released. Issue record

The problem arose from the interaction between package versions and installer selection rules. The original report said the ROCm 10.1.0 stable index contained a torchvision 0.29 package tagged a0. A generic installation without a version specified instead installed torch 2.14 and torchvision 0.28, which could cause errors such as the missing torchvision::nms operator when running applications like ComfyUI. A successful package download does not guarantee that the native extensions in those packages are compatible. Reproduction report

The fix had two parts. First, the torchvision wheel’s dependency metadata was made to pin the torch version used to build it, preventing the resolver from freely combining incompatible packages. Second, when building from the PyTorch release branch, the a0 suffix was removed from the package’s public version. The first change constrains binary pairing; the second addresses release-branch artifacts being treated as prerelease versions. Version-pinning patch, version-number patch

However, as of the time of verification, some ROCm 10.1.0 commands on AMD’s official installation page still explicitly specify torchvision==0.29.0a0+rocm10.1.0. Installing an exact version and installing without a version constraint may produce different resolution results, so documentation examples, index contents, and build workflows need to be checked separately. AMD installation documentation

For engineering teams maintaining AMD GPU inference environments, this incident highlights how package dependency declarations affect deployment reproducibility. Based on the failure mechanism described above, environment validation should record the index and complete package versions, then actually load the vision operators required by the application. Points to watch include whether the stable index and documentation are brought into sync, and whether the release workflow can automatically test the unpinned installation path. The public evidence currently consists primarily of installation output provided by the maintainers.