Change "Feature-freeze" lifecycle to "Frozen" state #3456
Conversation
| In addition to the statuses above, documents may be marked as `Feature-freeze`. These documents are not currently accepting new feature requests, to allow the Technical Committee time to focus on other areas of the specification. Editorial changes are still accepted. Changes that address production issues with existing features are still accepted. | ||
|
|
||
| Feature freeze is separate from a lifecycle status. The lifecycle represents the support requirements for the document, feature freeze only indicates the current focus of the specification community. The feature freeze label may be applied to a document at any lifecycle stage. By definition, deprecated documents have a feature freeze in place. | ||
| | Status | Explanation | |
There was a problem hiding this comment.
maybe? (otherwise, there is no difference between deprecated and stable)
| | Status | Explanation | | |
| | Status | Allowed changes | |
Co-authored-by: Liudmila Molkova <[email protected]>
|
I wonder if we need to settle on some common terminology. We use different terms depending what we talk about, but I am not sure there are good reasons. In some place we use Experimental/Frozen/Stable, some other places Alpha/Beta/Stable, somewhere else Unstable/Beta/Stable. See also https://github.com/open-telemetry/community/blob/main/maturity-matrix.yaml Should we chose one set of names and stick to it? The meaning of each term can still have contextual nuances. |
|
Discussed in HTTP semconv WG today and @jsuereth's preference is to not introduce a |
|
closing this in favor of discussion going on in #3459 |
Fixes #3455
Changes
Change "Feature-freeze" lifecycle to "Frozen" state.