Hi Team,
We are kicking off the PyTorch 2.6.0 release cycle!
WHEN ARE THE CRITICAL DATES FOR THE PYTORCH 2.6.0 RELEASE?
- M1: Call for features (11/4/24)
- M2: All PRs landed in PyTorch repo / Feature Submission Closed (12/6/24) - DEADLINE
- M3.1: Release branch cut (12/9/24)
- M3.2: Release first RC1 Binary for PyTorch Core (12/10/24)
- M3.3: Domain libraries cut RC Branch (12/11/24)
- M4: Release branch finalized, Announce final launch date, Feature classifications published (week of 1/13/25) - Final RC is produced.
- M4.1: Tutorial drafts submission deadline (1/15/25)
- M5: External-Facing Content Finalized (1/24/25)
- M6: Release Day (1/29/25)
Please read the blog posts for the 2.5 release to get familiar with the marketing format: PyTorch 2.5 Release Blog | PyTorch. Remember that to qualify for Beta status or Stable status requires release blogs and tutorials and CI Integration.
We are thrilled about all the great features from our PyTorch community! If you still have questions after reading the material below–or at anytime during the process–please don’t hesitate to contact one of us: Gregory Chanan, Ankith Gunapal, Alban Desmaison, Andrey Talman, Huy Do, Nikita Shulga, Eli Uriegas, and Sergii Dymchenko.
HOW DO I SUBMIT A FEATURE ?
Step 1: Add your feature to the PyTorch 2.6.0 feature list along with the submitter name. By EOD on 12/6/24, create a copy of the feature form here, complete it to the best of your ability, and link it into the feature list. (An example is here.)
Step 2: If you’ve submitted a feature–and your feature requires a review–you will be invited to a review meeting. Please note: Only a subset of features will require a review meeting.
Step 3: By 12/6/24 land your PRs and submit your features. This is the last day before the release cut.
Step 4: We will review and provide feedback for final edits for features highlighted in release notes by 1/13/25 and will publish feature classifications. Please read the PyTorch 2.5 blogs to see format, length, and style @ PyTorch 2.5 Release Blog | PyTorch. Remember to drop charts/images here. Remember our best practice: We do not compare or disparage competitors’ products or their stats; for example, don’t say that PyTorch is 10X better than another framework.
HOW DO I KNOW WHICH CLASSIFICATION TO USE?
Classification is based on our published classification guidance. In the end, this is a judgment call by the relevant teams, both the feature owners/contributors as well as the PyTorch maintainers and Technical Leads. With new features, we need to balance commitment and coverage. See below for how we think about how we define the classifications.
Stable: A stable feature means that the consumer value-add is or has been proven (note that consumer may not be the end user, but a component higher in the stack), the API isn’t expected to change, the feature is performant, and all documentation exists to support end-user adoption.
Beta: In the case of a Beta feature, the value add, similar to a Stable feature, has been proven (e.g. pruning is a commonly used technique for reducing the number of parameters in NN models, independent of the implementation details of our particular choices), and the feature generally works and is documented. This feature is tagged as Beta because the API may change based on user feedback, because the performance needs improvement, or because coverage across operators is not yet complete.
Prototype: In this case, we would like to get high bandwidth partner feedback ahead of a real release in order to gauge utility and to identify any changes we need to make to the UX. Such feature should be working at least for some limited use cases with appropriate per-function documentation. This feature can be changed significantly from one release to the next.
WHAT ELSE SHOULD I BE DOING?
Think about the appropriate artifacts for your feature classifications. You are responsible for the docs, tutorials/recipes, blog, or other content you need for the launch of your feature.
Cheers,
Team PyTorch
#oneteam