Skip to content

Commit 50104db

Browse files
mx-psiChrsMark
andauthored
[chore][docs/component-stability.md] Add a 'Moving between stability levels' section (open-telemetry#11937)
<!--Ex. Fixing a bug - Describe the bug and how this fixes the issue. Ex. Adding a feature - Explain what this achieves.--> #### Description Split off from open-telemetry#11864, describes how the graduation would work without any additional criteria. Rendered diagram: ```mermaid stateDiagram-v2 state Maintained { InDevelopment --> Alpha Alpha --> Beta Beta --> Stable } InDevelopment: In Development Maintained --> Unmaintained Unmaintained --> Maintained Maintained --> Deprecated Deprecated --> Maintained: (should be rare) ``` --------- Co-authored-by: Christos Markou <[email protected]>
1 parent 1ddd969 commit 50104db

File tree

1 file changed

+30
-0
lines changed

1 file changed

+30
-0
lines changed

docs/component-stability.md

+30
Original file line numberDiff line numberDiff line change
@@ -188,6 +188,36 @@ they have no active code owners from the vendor even if there are other code own
188188
owners may petition for its continued maintenance if they want, at which point the component will no
189189
longer be considered vendor-specific.
190190

191+
## Moving between stability levels
192+
193+
Components can move between stability levels. The valid transitions are described in the following diagram:
194+
195+
```mermaid
196+
stateDiagram-v2
197+
state Maintained {
198+
InDevelopment --> Alpha
199+
Alpha --> Beta
200+
Beta --> Stable
201+
}
202+
203+
InDevelopment: In Development
204+
205+
Maintained --> Unmaintained
206+
Unmaintained --> Maintained
207+
Maintained --> Deprecated
208+
Deprecated --> Maintained: (should be rare)
209+
```
210+
211+
To move within the 'Maintained' ladder ("graduate"), the process for doing so is as follows:
212+
213+
1. One of the component owners should file an issue with the 'Graduation' issue template to request
214+
the graduation.
215+
2. An approver is assigned in a rotating basis to evaluate the request and provide feedback. For
216+
vendor specific components, the approver should be from a different employer to the one owning
217+
the component.
218+
3. If approved, a PR to change the stability level should be opened and MUST be approved by all
219+
listed code owners.
220+
191221
## Versioning
192222

193223
Components are Go modules and as such follow [semantic versioning](https://semver.org/). Go API stability guarantees are covered in the [VERSIONING.md](../VERSIONING.md) document.

0 commit comments

Comments
 (0)