Description
RFC Authors: @anitakat @atalman
Hello everyone,
Following feedback and discussion on existing gaps of the feature review process, below are proposed changes for which we are keen to have your input.
Feature Tracking Process
Beginning with release 2.8, the PyTorch release will only track major features. At this time we do not have a comprehensive list and welcome examples from the community of what they would like tracked.
- All major features will require an RFC from the start with an estimated timeline. This will allow the maintainers to provide async feedback before feature implementation begins.
- The RFC for these major features will have a current status that will enable partners and the community at large, to reference the progress of a given feature with ease. Example of an RFC.
- These RFCs will be tagged and labelled appropriately for tracking and when a feature is complete/stable, they will be untagged and no longer tracked.
- Release notes will highlight new major features and improvements made to existing features, and will follow the new classification of Stable (API-Stable) and Unstable (API-Unstable).
For any features not on this list, the only requirement is to follow the path to stable below, to be classified as stable when ready.
Feature Classification:
Beginning with release 2.8, feature submissions will be classified as either Stable (API-Stable) or Unstable (API-Unstable), and the previous classifications of Prototype, Beta and Stable, will no longer be used.
Stable (API-Stable)
(Previously called Stable) An API-Stable feature means that the user value-add has been proven, the API isn’t expected to change, the feature is performant and all documentation exists to support end user adoption.
Examples of API-Stable features include Accelerated Transformers, DataLoader, Autograd Engine, and CUDA support in PyTorch CI/CD.
Commitment from the PyTorch team: We expect to maintain these features long term and generally there should be no major performance limitations or gaps in documentation. We also expect to maintain backwards compatibility (although breaking changes can happen and notice will be given one release ahead of time).
Unstable (API-Unstable)
(Previously Prototype or Beta) Encompasses all features that are under active development where API may change based on user feedback, requisite performance improvements or because coverage across operators is not yet complete.
Commitment from the PyTorch team: We are not committing to backwards compatibility. The APIs and performance characteristics of this feature may change.
Classification Requirements
Requirement | Unstable (API-Unstable) | Stable (API-Stable) | Path to Stable (API-Stable) |
---|---|---|---|
RFC Created | X | X | - |
Doc Strings | X | X | - |
Unit Tests | X | X | - |
CI Coverage | X | X | - |
Complete Workflow Coverage (e.g. CV or NLP) | X | Phase 1 | |
Recipe or Tutorial | X | Phase 1 | |
User Feedback (Features with User API surface) | X | Phase 2 | |
Dogfooding: 1-2 early adopter teams (internal or external) have found this feature useful and their feedback has been incorporated | X | Phase 2 | |
Design review / TL Signoff | X | Phase 2 | |
API Stability | X | - | |
Full Op Coverage | X | - |
Path To Stable API

Thank you for reading and we look forward to your feedback.
Cheers,
Team PyTorch