[Public Viewable] PyTorch/DAPI Feature List (2.4, 2.3, 2.2 - 1.12) - OSS

	A	B	C	D	E
1
2	[PUBLIC] This table is viewable to public. Please do not disclose internal content
3
4	Requirement	Prototype	Beta	Stable	*** Can be internal, team members, external users
5	Doc Strings	X	X	X	Stable: Nothing changes here. A stable feature means that the user value-add is or has been proven, the API isn’t expected to change, the feature is performant and all documentation exists to support end user adoption. Level of commitment: We expect to maintain these features long term and generally there should be no major performance limitations, gaps in documentation and we also expect to maintain backwards compatibility (although breaking changes can happen and notice will be given one release ahead of time).
6	Unit Tests	X	X	X
7	CI Coverage	X	X	X
8	Design review / TL Signoff		X	X
9	Complete Workflow Coverage (e.g. CV or NLP)		X	X
10	Recipe or Tutorial		X	X
11	User Feedback (Features with User API surface)***		X	X
12	Dogfooding: 1-2 early adopter teams (internal or external) have found this feature useful and their feedback has been incorporated		X	X	Beta: We previously called these features ‘Experimental’ and we found that this created confusion amongst some of the users. 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. Level of commitment: We are committing to seeing the feature through to the Stable classification. We are however not committing to Backwards Compatibility. Users can depend on us providing a solution for problems in this area going forward, but the APIs and performance characteristics of this feature may change.
13	API Stability			X
14	Full Op Coverage			X
15	Top-line adoption metrics (internal or external), feedback from major companies and AI researchers has been incorporated			X
16
17
18
19
20
21					Prototype: Previously these were features that were known about by developers who paid close attention to RFCs and to features that land in master. 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. Level of commitment: We are committing to gathering high bandwidth feedback only. Based on this feedback and potential further engagement between community members, we as a community will decide if we want to upgrade the level of commitment or to fail fast. Additionally, while some of these features might be more speculative (e.g. new Frontend APIs), others have obvious utility (e.g. model optimization) but may be in a state where gathering feedback outside of high bandwidth channels is not practical, e.g. the feature may be in an earlier state, may be moving fast (PRs are landing too quickly to catch a major release) and/or generally active development is underway.
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100