同步操作将从 dairenjie/pytorch 强制同步,此操作会覆盖自 Fork 仓库以来所做的任何修改,且无法恢复!!!
确定后同步将在后台操作,完成时将刷新页面,请耐心等待。
Following is the Release Compatibility Matrix for PyTorch releases:
PyTorch version | Python | Stable CUDA | Experimental CUDA |
---|---|---|---|
2.2 | >=3.8, <=3.11, (3.12 experimental) | CUDA 11.8, CUDNN 8.7.0.84 | CUDA 12.1, CUDNN 8.9.2.26 |
2.1 | >=3.8, <=3.11 | CUDA 11.8, CUDNN 8.7.0.84 | CUDA 12.1, CUDNN 8.9.2.26 |
2.0 | >=3.8, <=3.11 | CUDA 11.7, CUDNN 8.5.0.96 | CUDA 11.8, CUDNN 8.7.0.84 |
1.13 | >=3.7, <=3.10 | CUDA 11.6, CUDNN 8.3.2.44 | CUDA 11.7, CUDNN 8.5.0.96 |
1.12 | >=3.7, <=3.10 | CUDA 11.3, CUDNN 8.3.2.44 | CUDA 11.6, CUDNN 8.3.2.44 |
Following is the release cadence for year 2023/2024. All dates below are tentative, for latest updates on the release scheduled please follow dev discuss.
Minor Version | Release branch cut | Release date | First patch release date | Second patch release date |
---|---|---|---|---|
2.1 | Aug 2023 | Oct 2023 | Nov 2023 | Dec 2023 |
2.2 | Dec 2023 | Jan 2024 | Feb 2024 | Mar 2024 |
2.3 | Mar 2024 | Apr 2024 | May 2024 | Jun 2024 |
2.4 | May 2024 | Jul 2024 | Aug 2024 | Sep 2024 |
2.5 | Aug 2024 | Oct 2024 | Nov 2024 | Dec 2024 |
Releasing a new version of PyTorch generally entails 3 major steps:
Q: What is release branch cut ?
main
development branch of PyTorch. This allows PyTorch development flow on main
to continue uninterrupted, while the release engineering team focuses on stabilizing the release branch in order to release a series of release candidates (RC). The activities in the release branch include both regression and performance testing as well as polishing new features and fixing release-specific bugs. In general, new features are not added to the release branch after it was created.Q: What is cherry-pick ?
Following Requirements needs to be met prior to cutting a release branch:
python github_analyze.py --repo-path ~/local/pytorch --remote upstream --branch release/1.11 --milestone-id 26 --missing-in-branch
pytorch/pytorch
Release branches are typically cut from the branch viable/strict
as to ensure that tests are passing on the release branch.
There's a convenience script to create release branches from current viable/strict
. Perform following actions :
git clone git@github.com:pytorch/pytorch.git
DRY_RUN=disabled scripts/release/cut-release-branch.sh
This script should create 2 branches:
release/{MAJOR}.{MINOR}
orig/release/{MAJOR}.{MINOR}
pytorch/builder
/ PyTorch domain librariesNote: Release branches for individual domain libraries should be created after first release candidate build of PyTorch is available in staging channels (which happens about a week after PyTorch release branch has been created). This is absolutely required to allow sufficient testing time for each of the domain library. Domain libraries branch cut is performed by Domain Library POC.
Builder branch cut should be performed at the same time as Pytorch core branch cut. Convenience script can also be used domains as well as pytorch/builder
NOTE: RELEASE_VERSION only needs to be specified if version.txt is not available in root directory
DRY_RUN=disabled GIT_BRANCH_TO_CUT_FROM=main RELEASE_VERSION=1.11 scripts/release/cut-release-branch.sh
These are examples of changes that should be made to release branches so that CI / tooling can function normally on them:
pytorch/xla
and pytorch/builder
repos and pinned in pytorch/pytorch
for i in .github/workflows/*.yml; do sed -i -e s#@main#@release/2.0# $i; done
These are examples of changes that should be made to the default branch after a release branch is cut
Domain library branch cut is done a week after branch cut for the pytorch/pytorch
. The branch cut is performed by the Domain Library POC.
After the branch cut is performed, the Pytorch Dev Infra member should be informed of the branch cut and Domain Library specific change is required before Drafting RC for this domain library.
Follow these examples of PR that updates the version and sets RC Candidate upload channel:
The series of meetings for Core XFN sync should be organized. The goal of these meetings are the following:
Following POC's should be assigned from each of the workstreams:
NOTE: The meetings should start after the release branch is created and should continue until the week of the release.
To draft RCs, a user with the necessary permissions can push a git tag to the main pytorch/pytorch
git repository. Please note: exactly same process is used for each of the domain library
The git tag for a release candidate must follow the following format:
v{MAJOR}.{MINOR}.{PATCH}-rc{RC_NUMBER}
An example of this would look like:
v1.12.0-rc1
You can use following commands to perform tag from pytorch core repo (not fork):
git checkout release/1.12
git log --oneline
git tag -f v1.12.0-rc2
git push origin v1.12.0-rc2
Pushing a release candidate should trigger the binary_builds
workflow within CircleCI using pytorch/pytorch-probot
's trigger-circleci-workflows
functionality.
This trigger functionality is configured here: pytorch-circleci-labels.yml
To view the state of the release build, please navigate to HUD. And make sure all binary builds are successful.
Release candidates are currently stored in the following places:
Backups are stored in a non-public S3 bucket at s3://pytorch-backup
Validate the release jobs for pytorch and domain libraries should be green. Validate this using following HUD links:
Validate that the documentation build has completed and generated entry corresponding to the release in docs folder of pytorch.github.io repository
Typically, within a release cycle fixes are necessary for regressions, test fixes, etc.
For fixes that are to go into a release after the release branch has been cut we typically employ the use of a cherry pick tracker.
An example of this would look like:
Please also make sure to add milestone target to the PR/issue, especially if it needs to be considered for inclusion into the dot release.
NOTE: The cherry pick process is not an invitation to add new features, it is mainly there to fix regressions
You can now use pytorchbot
to cherry pick a PyTorch PR that has been committed
to the main branch using @pytorchbot cherry-pick
command as follows.
usage: @pytorchbot cherry-pick --onto ONTO [--fixes FIXES] -c
{regression,critical,fixnewfeature,docs,release}
Cherry pick a pull request onto a release branch for inclusion in a release
optional arguments:
--onto ONTO Branch you would like to cherry pick onto (Example: release/2.2)
--fixes FIXES Link to the issue that your PR fixes (i.e. https://github.com/pytorch/pytorch/issues/110666)
-c {regression,critical,fixnewfeature,docs,release}
A machine-friendly classification of the cherry-pick reason.
For example, #120567
created a cherry pick PR #121232 onto release/2.2
branch to fix a regression issue. You can then refer to the original
and the cherry-picked PRs on the release tracker issue. Please note
that the cherry-picked PR will still need to be reviewed by PyTorch
RelEng team before it can go into the release branch. This feature
requires pytorchbot
, so it's only available in PyTorch atm.
If PR that has been cherry-picked into release branch has been reverted, it's cherry-pick must be reverted as well.
Reverts for changes that was committed into the main branch prior to the branch cut, must be propagated into release branch as well.
The following requirements need to be met prior to creating final Release Candidate :
Resolve all outstanding open issues in the milestone. There should be no open issues/PRs (for example 2.1.2). The issue should either be closed or de-milestoned.
Validate that all closed milestone PRs are present in the release branch. Confirm this by running:
python github_analyze.py --repo-path ~/local/pytorch --remote upstream --branch release/2.2 --milestone-id 40 --missing-in-branch
No outstanding cherry-picks that need to be reviewed in the issue tracker: https://github.com/pytorch/pytorch/issues/115300
Perform Release Candidate health validation. CI should have the green signal.
After the final RC is created. The following tasks should be performed :
Perform Release Candidate health validation. CI should have the green signal.
Run and inspect the output Validate Binaries workflow.
All the closed issues from milestone need to be validated. Confirm the validation by commenting on the issue: https://github.com/pytorch/pytorch/issues/113568#issuecomment-1851031064
Create validation issue for the release, see for example Validations for 2.1.2 release and perform required validations.
Run performance tests in benchmark repository. Make sure there are no prerformance regressions.
Prepare and stage PyPI binaries for promotion. This is done with this script:
pytorch/builder:release/pypi/promote_pypi_to_staging.sh
Validate staged PyPI binaries. Make sure generated packages are correct and package size does not exceeds maximum allowed PyPI package size.
Promotion of RCs to stable is done with this script:
pytorch/builder:release/promote.sh
Users of that script should take care to update the versions necessary for the specific packages you are attempting to promote.
Promotion should occur in two steps:
NOTE: The promotion of wheels to PyPI can only be done once so take caution when attempting to promote wheels to PyPI, (see https://github.com/pypa/warehouse/issues/726 for a discussion on potential draft releases within PyPI)
The following should be prepared for the release day
Need to modify release matrix for get started page. See following PR as reference.
The PR to update published_versions.json and quick-start-module.js is auto generated. See following PR as reference.
Please note: This PR needs to be merged on the release day and hence it should be absolutely free of any failures. To test this PR, open another test PR but pointing to the Release candidate location as above Release Candidate Storage
This is normally done right after the release is completed. We would need to create Google Colab Issue see following PR
A patch release is a maintenance release of PyTorch that includes fixes for regressions found in a previous minor release. Patch releases typically will bump the patch
version from semver (i.e. [major].[minor].[patch]
).
Please note: Starting from 2.1 one can expect up to 2 patch releases after every minor ones. Patch releases would only be published for latest minor release.
Patch releases should be considered if a regression meets the following criteria:
NOTE: Patch releases should only be considered when functionality is broken, documentation does not typically fall within this category
Main POC: Patch Release Managers, Triage Reviewers
Patch releases should follow these high-level phases. This process starts immediately after the previous release has completed. Patch release process takes around 4-5 weeks to complete.
Main POC: Triage Reviewers
triage review
1.9.1
) if the regressions is found to be within the Patch Release Criteria
For patch releases issue tracker needs to be created. For patch release, we require all cherry-pick changes to have links to either a high-priority GitHub issue or a CI failure from previous RC. An example of this would look like:
Only following issues are accepted:
Main POC: Patch Release Managers
release/1.9
for 1.9.1
)
Main POC: Patch Release managers
PyTorch has a support matrix across a couple of different axis. This section should be used as a decision making framework to drive hardware / software support decisions
For versions of Python that we support we follow the NEP 29 policy, which was originally drafted by numpy.
For accelerator software like CUDA and ROCm we will typically use the following criteria:
In some instances support for a particular version of software will continue if a need is found. For example, our CUDA 11 binaries do not currently meet the size restrictions for publishing on PyPI so the default version that is published to PyPI is CUDA 10.2.
These special support cases will be handled on a case by case basis and support may be continued if current PyTorch maintainers feel as though there may still be a need to support these particular versions of software.
Tutorials in support of a release feature must be submitted to the pytorch/tutorials repo at least two weeks before the release date to allow for editorial and technical review. There is no cherry-pick process for tutorials. All tutorials will be merged around the release day and published at pytorch.org/tutorials.
In the event a submodule cannot be fast forwarded, and a patch must be applied we can take two different approaches:
Editing submodule remotes can be easily done with: (running from the root of the git repository)
git config --file=.gitmodules -e
An example of this process can be found here:
In nightly builds for conda and wheels pytorch depend on Triton build by this workflow: https://hud.pytorch.org/hud/pytorch/pytorch/nightly/1?per_page=50&name_filter=Build%20Triton%20Wheel. The pinned version of triton used by this workflow is specified here: https://github.com/pytorch/pytorch/blob/main/.ci/docker/ci_commit_pins/triton.txt .
In Nightly builds we have following configuration:
However for release we have following :
Important: The release of https://pypi.org/project/triton/ needs to be requested from OpenAI once branch cut is completed. Please include the release PIN hash in the request: https://github.com/pytorch/pytorch/blob/release/2.1/.ci/docker/ci_commit_pins/triton.txt .
此处可能存在不合适展示的内容,页面不予展示。您可通过相关编辑功能自查并修改。
如您确认内容无涉及 不当用语 / 纯广告导流 / 暴力 / 低俗色情 / 侵权 / 盗版 / 虚假 / 无价值内容或违法国家有关法律法规的内容,可点击提交进行申诉,我们将尽快为您处理。