Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support stability definitions from OTEP 232 #1096

Closed
1 of 3 tasks
lmolkova opened this issue May 30, 2024 · 1 comment · Fixed by #1889
Closed
1 of 3 tasks

Support stability definitions from OTEP 232 #1096

lmolkova opened this issue May 30, 2024 · 1 comment · Fixed by #1889
Assignees
Labels
enhancement New feature or request

Comments

@lmolkova
Copy link
Contributor

lmolkova commented May 30, 2024

See open-telemetry/opentelemetry-specification#4061

We need to support new formally defined (in OTEP 232) maturity levels:

  • Development - add
  • Alpha - add
  • Beta - add
  • Release Candidate - add
  • Stable - no change
  • Deprecated - no change
  • Unmaintained - don't add for now

Experimental stability should default to development, but can be changed for each group/document to a higher (non-stable) level.

This would mean:

@lmolkova lmolkova added enhancement New feature or request experts needed This issue or pull request is outside an area where general approvers feel they can approve triage:needs-triage labels May 30, 2024
@trask
Copy link
Member

trask commented May 30, 2024

I think @jack-berg's open-telemetry/opentelemetry-specification#4061 (comment) could apply to this repo as well

Not sure how appropriate development is for spec language. Given that even experimental spec components require prototypes to merge, it seems like most new features in the spec come in at the alpha level of stability.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants