Skip to content

[RFC] Proposed Changes to Feature Tracking & Classification for PyTorch Releases starting Release 2.8 #152134

Open
@atalman

Description

@atalman

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

Image

Thank you for reading and we look forward to your feedback.

Cheers,

Team PyTorch

Metadata

Metadata

Assignees

No one assigned

    Labels

    triagedThis issue has been looked at a team member, and triaged and prioritized into an appropriate module

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions