PyTorch Call for Features - 2.0

TL;DR: Starting the PyTorch 2.0 release cycle now to ship for early March, follow instructions to submit your feature (and/or upgrade to Beta/Stable) by 1/12/2023.

Hi Team,

We are kicking off the PyTorch 2.0 release cycle! We announced 2.0 on 12/02 at the New Orlean’s PyTorch Conference, social media and PyTorch 2.0 | PyTorch, We also communicated that we “expect to ship the first stable 2.0 release in early March 2023”, so we are kicking off the process to meet that promise!

As we’ve done the past several releases, most recently 1.13 on 10/28, 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 March release.

Some key dates: our next release cycle will start today, the feature submission deadline is set on 1/12, feature reviews are scheduled on week of 1/16 and 1/23. Release Eng team will cut the release branch for pytorch/pytorch on 2/13, and target an early March release that factors in enough time for QA, Linux Foundation and other approvals. Please read the 1.13 blog posts to get familiar with the marketing format at PyTorch 1.13 release, including beta versions of functorch and improved support for Apple’s new M1 chips. | PyTorch. Remember Beta/Steble require release blogs and tutorials.

We are thrilled about all the great features from our PyTorch community! If you still have any questions after reading below or throughout the process please don’t hesitate to contact PM/TPM POCs Jerry Park and Jason Liang.


HOW DO I SUBMIT A FEATURE?

Step 1: Add your feature to the PyTorch 2.0 feature list along with the submitter name. By EOD on 1/12, create a copy of the feature submission form here, complete it to the best of your ability and link it into the feature list

Step 2: If you’ve submitted a feature, you will be invited to a review the weeks of 1/16 or 1/23 and, we as a team, will make a decision how each feature will be classified in the release by the week of 1/30.

Step 3: By 2/10 land your PRs. This is the last day before the release cut. This is critical for release engineering to know which ones to focus on when cutting the release branch and for cherry picking purposes (although please keep this to a min!)

Step 4: If you requested Marketing/Blog support (see Step 1) submit your draft blogs here by 2/21. We will review and provide feedback for final edits by 2/28. Please read 1.13 to see format, length and style @ PyTorch 1.13 release, including beta versions of functorch and improved support for Apple’s new M1 chips. | PyTorch. Remember to drop charts/images here. Remember best practice: we do not compare or disparage competitor products or their stats (e.g., we are 10X better than TensorFlow).

Continuing LIGHTER-WEIGHT PROCESS FOR PROTOTYPE FEATURE

Also in 2.0, we plan to reduce the burden to submit prototype features to encourage experimentation, while balancing the quality of submission. As such, we will piloting the following process changes:

  1. Lighter documentation - submission doc for prototype feature focus on adopter feedback and plans to reach stable; rest fields are optional.
  2. Offline review - the synchronous feature review of prototype features should be done on need-basis. Feedback is provided offline.
HOW DO I KNOW WHICH CLASSIFICATION TO USE?

The guideline will be based on published classification here. In the end this is a judgment call by the 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 these are defined:

Stable: A stable feature means that the consumer value-add is or has been proven (note 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 level features, 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 to improve 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 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 whls that are made available on pytorch.org. For each prototype feature, a pointer to draft docs or other instructions will be provided.

ARTIFACT REQUIREMENT UPDATED

You are responsible for the docs, tutorials/recipes, blog or other content you need for the launch of your feature. The requirement table now fully specifies the requirement for artifacts per classification level, found in the feature submission template (link), based on above pytorch/dapi release feature type definitions.

WHAT ELSE SHOULD I BE DOING?
  1. If you’ve submitted a feature for PyTorch 2.0, look for an invite the week of 1/16 or 1/23 to discuss the classification of it;
  2. 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.
WHEN ARE THE CRITICAL DATES FOR THE PYTORCH 2.0 RELEASE? (See also picture)
  • M1: Call for feature (12/13/2022)
  • M2.1: Feature Submission Closed (01/12) - DEADLINE
  • M2.2: Publish feature inclusion and classification decision (week of 1/30)
  • M2.3: Landed all PRs in PyTorch repo (2/10)
  • M3.1: Release branch cut (2/13) - DEADLINE
  • M3.2: Release first RC1 Binary for PyTorch Core (2/14)
  • M3.3: Domain libraries to cut RC Branch (2/17)
  • M4: Release Branched Finalized & Announce Final launch date (week of 2/27)
  • M5: External-Facing Material Content Finalized (targeting beginning of March)
  • M6: Release Day (targeting beginning of March)

Cheers,

Team PyTorch

1 Like

Hi PyTorch team
Could you also please list down the third_party package versions targeted for PyTorch 2.0 release? I’m mainly interested in onednn and ideep versions.

Thank you!

Hello,
Our current version was updated by this PR: upgrade oneDNN to v2.7.2 Upgrade oneDNN to v2.7.2 by yanbing-j · Pull Request #90051 · pytorch/pytorch · GitHub on Dec 2. I have no knowledge if we are planning to advance it for the release currently. Forwarded your question to a person who does updates for these modules. Will update you once I have this information.

If you want to update the package, please do not hesitate to propose a PR. If there are no major backward incompatible API changes in new version of ideep, I don’t see why it shouldn’t be updated.

thanks @atalman and @malfet . oneDNN 2.7.2 sounds good. regarding ideep, I’m not clear on which branch is targeted for pytorch release, I will check it in the ideep repo discussion.

I would like to call out C++17 as sort of a dev feature for PyTorch

PyTorch 2.0 | Feature Review Complete

Last week we completed the “feature review” milestone for the upcoming PyTorch Major Release 2.0 in early March. On 1/12/23, we received 36 feature submissions and in our four day review cycle, approved 17 Beta/Stable] features. Thanks to everyone who has diligently documented and presented the feature in the feature submission process.

Summary

In 2.0, here are some major highlights:

  • Torch.compile() going beta!

  • Received 16 Prototype features.

  • Seeing great development traction in domain libraries (TorchText, TorchRL, TorchAudio, and TorchRec).

  • Receiving participation and feature submissions from non-meta developers (Intel and University of Toronto).

  • Adding major backend features to expand platform support and introducing important Prototype to Beta features that improve performance.

What is next?

In addition to driving key marketing deliverables with submitters, the team is targeting to cut the release candidate branch of the PyTorch/PyTorch core repo in 2/13 (please land all PR by 2/10).

  • Landed all PRs in PyTorch repo (2/10)

  • Release branch cut (2/13) -** DEADLINE

  • Release first RC1 Binary for PyTorch Core (2/14)

  • Domain libraries to cut RC Branch (2/17)

  • Last Cherry Pick (2/27)

Area of Improvement for future reviews

In this iteration of the feature review, we have heard some great feedback on the process. This includes 1) how to better categorize and fast track reviews of ‘performance enhancement only’ features where there are no API changes; 2) improve the feature templates to ensure adoption, metrics and path to Stable are submitted before review; 3) integrate Linux Foundation/PyTorch Foundation into the release process; and 4) better documentation of domain and release engineering RACI/process.