You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
## Changes
This change brings the specification lifecycle phases in alignment with
OTEP-232 which defines the maturity levels for OTel in general. Most of
the changes should be non-contentious, but one aspect deserves
discussion: should feature-freeze be mapped to Release Candidate?
* [x] Related [OTEP(s)](https://github.com/open-telemetry/oteps): 232
Should the changelog be updated to include this change?
Signed-off-by: Juraci Paixão Kröhling <[email protected]>
---------
Signed-off-by: Juraci Paixão Kröhling <[email protected]>
Co-authored-by: Carlos Alberto Cortez <[email protected]>
Copy file name to clipboardExpand all lines: specification/document-status.md
+12-8Lines changed: 12 additions & 8 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -5,26 +5,30 @@ shown immediately after the document title. When present, the "Status" applies
5
5
to the individual document only and not to the entire specification or any other
6
6
documents. The following table describes what the statuses mean.
7
7
8
-
## Lifecycle status
8
+
## Maturity levels
9
9
10
-
The support guarantees and allowed changes are governed by the lifecycle of the document.Lifecycle stages are defined in the [Versioning and Stability](versioning-and-stability.md) document.
10
+
The support guarantees and allowed changes are governed by the maturity level of the document. Maturity levels are defined in [OTEP 0232](../oteps/0232-maturity-of-otel.md#explanation) and follow the OpenTelemetry project's standard framework for describing component maturity.
11
11
12
12
|Status |Explanation|
13
13
|--------------------|-----------|
14
-
|No explicit "Status"|Equivalent to Development.|
15
-
|Development |Breaking changes are allowed.|
16
-
|Stable |Breaking changes are no longer allowed. See [stability guarantees](versioning-and-stability.md#stable) for details.|
17
-
|Deprecated |Changes are no longer allowed, except for editorial changes.|
14
+
|No explicit "Status"|Equivalent to Alpha.|
15
+
|Development |Not all pieces of the component are in place yet, and it might not be available for users yet. Bugs and performance issues are expected to be reported. User feedback around the UX of the component is desired, such as for configuration options, component observability, technical implementation details, and planned use-cases for the component. Configuration options might break often depending on how things evolve. The component SHOULD NOT be used in production. The component MAY be removed without prior notice.|
16
+
|Alpha |The component is ready to be used for limited non-critical production workloads, and the authors of this component welcome user feedback. Bugs and performance problems are encouraged to be reported, but component owners might not work on them immediately. The component's interface and configuration options might often change without backward compatibility guarantees. Components at this stage might be dropped at any time without notice.|
17
+
|Beta |Same as Alpha, but the interfaces (API, configuration, generated telemetry) are treated as stable whenever possible. While there might be breaking changes between releases, component owners should try to minimize them. A component at this stage is expected to have had exposure to non-critical production workloads already during its Alpha phase, making it suitable for broader usage.|
18
+
|Release Candidate |The component is feature-complete and ready for broader usage. The component is ready to be declared stable, it might just need to be tested in more production environments before that can happen. Bugs and performance problems are expected to be reported, and there's an expectation that the component owners will work on them. Breaking changes, including configuration options and the component's output, are only allowed under special circumstances. Whenever possible, users should be given prior notice of the breaking changes.|
19
+
|Stable |The component is ready for general availability. Bugs and performance problems should be reported, and there's an expectation that the component owners will work on them. Breaking changes, including configuration options and the component's output, are only allowed under special circumstances. Whenever possible, users should be given prior notice of the breaking changes. See [stability guarantees](versioning-and-stability.md#stable) for details.|
20
+
|Deprecated |Development of this component is halted. No new versions are planned, and the component might be removed from its included distributions. Note that new issues will likely not be worked on except for critical security issues. Components that are included in distributions are expected to exist for at least two minor releases or six months, whichever happens later. They also MUST communicate in which version they will be removed.|
21
+
|Unmaintained |A component identified as unmaintained does not have an active code owner. Such components may have never been assigned a code owner, or a previously active code owner has not responded to requests for feedback within 6 weeks of being contacted. Issues and pull requests for unmaintained components SHOULD be labeled as such. After 6 months of being unmaintained, these components MAY be deprecated. Unmaintained components are actively seeking contributors to become code owners.|
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.
29
+
In addition to the maturity levels 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.
26
30
27
-
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.
31
+
Feature freeze is separate from a maturity level. The maturity level 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 maturity level. By definition, deprecated documents have a feature freeze in place.
0 commit comments