Skip to content

Commit

Permalink
[chore][docs/component-stability.md] Add a 'Moving between stability …
Browse files Browse the repository at this point in the history
…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]>
  • Loading branch information
mx-psi and ChrsMark authored Dec 19, 2024
1 parent 1ddd969 commit 50104db
Showing 1 changed file with 30 additions and 0 deletions.
30 changes: 30 additions & 0 deletions docs/component-stability.md
Original file line number Diff line number Diff line change
Expand Up @@ -188,6 +188,36 @@ they have no active code owners from the vendor even if there are other code own
owners may petition for its continued maintenance if they want, at which point the component will no
longer be considered vendor-specific.

## Moving between stability levels

Components can move between stability levels. The valid transitions are described in the following 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)
```

To move within the 'Maintained' ladder ("graduate"), the process for doing so is as follows:

1. One of the component owners should file an issue with the 'Graduation' issue template to request
the graduation.
2. An approver is assigned in a rotating basis to evaluate the request and provide feedback. For
vendor specific components, the approver should be from a different employer to the one owning
the component.
3. If approved, a PR to change the stability level should be opened and MUST be approved by all
listed code owners.

## Versioning

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.
Expand Down

0 comments on commit 50104db

Please sign in to comment.