PyTorch Call for Features - 2.1.0
TL;DR: Starting with the PyTorch 2.1.0 release cycle–now scheduled to ship in early October–follow these instructions to submit your feature (and/or upgrade to Beta/Stable). Deadline to complete feature submission is 7/10/2023.
Hi Team,
We are kicking off the PyTorch 2.1.0 release cycle! We will be taking feature submissions and reviewing them to gauge how we should classify each feature in order to set proper expectations with users. This document walks you through a step-by-step process for how to get your feature officially into the October release.
We want to make small modifications to the release process at this stage, to make it more lightweight. Feature review will happen mostly async. The Feature Review council will flag specific features for review and schedule a meeting if required. With async review and signoff, the submission and implementation phases can happen mostly in parallel. (See the table at the end of this document for a description of the Feature Review council.)
Some key dates: Our next release cycle starts today; the feature submission deadline is 7/10/2023, feature reviews are scheduled on the weeks of 7/17, 7/24, 7/31, and 8/7. The Release Eng team will cut the release branch for pytorch/pytorch on 8/28, and target an early October release that factors in enough time for QA, Linux Foundation, and other approvals. Please read the blog posts for the 2.0 release to get familiar with the marketing format: https://pytorch.org/blog/PyTorch-2.0-release/. Remember that to qualify for Beta status or Stable status requires release blogs and tutorials.
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: Chris Gottbrath, Christian Keller, Andrey Talman, Nikita Shulga and Eli Uriegas
WHEN ARE THE CRITICAL DATES FOR THE PYTORCH 2.1.0 RELEASE? (See also picture)
- M1: Call for feature (5/22/2023)
- M2.1: Feature Submission Closed (07/10/23) - DEADLINE
- M2.2: Publish feature inclusion and classification decisions (week of 8/14)
- M2.3: All PRs landed in PyTorch repo (8/25)
- M3.1: Release branch cut (08/28/23) - DEADLINE
- M3.2: Release first RC1 Binary for PyTorch Core (8/29/23)
- M3.3: Domain libraries cut RC Branch (08/31/23)
- M4: Release Branch Finalized & Announce Final launch date (week of 09/11/23)
- M5: External-Facing Content Finalized (09/25/23)
- M6: Release Day (10/04/23)
HOW DO I SUBMIT A FEATURE?
Step 1: Add your feature to the PyTorch 2.1.0 feature list along with the submitter name. By EOD on 7/10, create a copy of the feature submission 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 the weeks of 7/17, 7/24, 7/31, 8/7. By the week of 8/21, we as a team will decide how each feature will be classified in the release. Please note: Only a subset of features will require a review meeting.
Step 3: By 8/25 land your PRs. This is the last day before the release cut. This is critical for release engineering to know which PRs to focus on when cutting the release branch and for cherry picking purposes (although please keep this to a minimum!)
Step 4: If you requested Marketing/Blog support (see Step 1) submit your draft blogs here by 9/5. We will review and provide feedback for final edits by 9/12. Please read the PyTorch 2.0 blogs to see format, length, and style @ https://pytorch.org/blog/PyTorch-2.0-release/. 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 we are 10X better than TensorFlow.
CONTINUING LIGHTER-WEIGHT PROCESS FOR FEATURES
In 2.1, we plan to reduce the burden for submitting features in order to encourage experimentation–while at the same time, maintaining submission quality. As such, we are piloting the following process changes:
- Offline review - synchronous feature review of features should be done only on an as-needed basis. Feedback is provided offline. The Feature Review council will flag specific features for review and schedule an in-person meeting if required.
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, the feature is not available as part of binary distributions like PyPI or Conda (except maybe behind run-time flags), but we would like to get high bandwidth partner feedback [see #Dogfooding]) ahead of a real release in order to gauge utility and to identify any changes we need to make to the UX. To test these kinds of features we would–depending on the feature–recommend building from master or using the nightly wheels that are made available on pytorch.org. For each prototype feature, a pointer to draft docs or other instructions is provided.
ARTIFACT REQUIREMENT UPDATED
You are responsible for the docs, tutorials/recipes, blogs, or other content you need for the launch of your feature. The Requirement table now fully specifies the requirements for artifacts at each classification level, found in the Feature Submission Template (link). The table is based on the pytorch/dapi release feature type definitions that are described above.
WHAT ELSE SHOULD I BE DOING?
- If you’ve submitted a feature for PyTorch 2.1.0, look for an invite the week of 7/17, 7/24, 7/31, or 8/7 to discuss how the feature should be classified.
- Think about the appropriate artifacts for your feature classification. You are responsible for the docs, tutorials/recipes, blog, or other content you need for the launch of your feature.
Cheers,
Team PyTorch
#oneteam