From 39ba8efd7c5de76a72dd39854011c02a43867c20 Mon Sep 17 00:00:00 2001 From: Andrey Talman Date: Tue, 25 Jul 2023 15:36:52 -0400 Subject: [PATCH] Update 2020-07-28-pytorch-feature-classification-changes.md Update Feature classification, to reflect current reality. The prototype features are included in the release and are part of released binaries https://pytorch.org/blog/pytorch-feature-classification-changes/ --- _posts/2020-07-28-pytorch-feature-classification-changes.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_posts/2020-07-28-pytorch-feature-classification-changes.md b/_posts/2020-07-28-pytorch-feature-classification-changes.md index 1ace6ef10388..9ff4291513aa 100644 --- a/_posts/2020-07-28-pytorch-feature-classification-changes.md +++ b/_posts/2020-07-28-pytorch-feature-classification-changes.md @@ -25,7 +25,7 @@ We previously called these features ‘Experimental’ and we found that this cr ## 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 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. +Previously these were features that were known about by developers who paid close attention to RFCs and to features that land in master. These features are part of the release and are available as part of binary distributions like PyPI or Conda. We would like to get high bandwidth partner feedback ahead of a real release in order to gauge utility and any changes we need to make to the UX. 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.