-
Notifications
You must be signed in to change notification settings - Fork 925
Update spec to comply with OTEP-232 #4529
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
Update spec to comply with OTEP-232 #4529
Conversation
Signed-off-by: Juraci Paixão Kröhling <[email protected]>
Signed-off-by: Juraci Paixão Kröhling <[email protected]>
To me Experimental + Feature-Freeze => Release candidate, but curious what other @open-telemetry/technical-committee folks think. IIRC - we did use Feature-Freeze on Stable components as well to denote no expected additions / features while implementation caught up. I think moving to just Stable at this point is ok. |
It's not entirely clear to me, but is there an action item for me? How can we move this forward? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you please also file issues with all other SIGs to update their statuses to match OTEP232 requirements?
My understanding is that Feature-freeze is not a maturity level. It indicates that no new changes are being accepted to the document. It does not claim a particular stability/maturity level and potentially can be used with any maturity level. I am not sure Experimental + Feature-Freeze is necessarily an indication of a Release candidate. Experimental is/was the least stable level, so how can it become a Release candidate with just a Feature freeze? |
Absolutely, once this one is merged, I'll file the issues and point to this PR for reference. |
Folks, can you please help me understand what's needed from me to move this forward? |
I like the idea (for now at least) to separate Feature Freeze from the stability level. @jsuereth think this is a good compromise (for now)? |
From the last Spec call, we discussed that:
|
This PR was marked stale due to lack of activity. It will be closed in 7 days. |
Follow up to #4529 Discussed this recently during the Specification call and there was initial agreement regarding removing Feature Freeze (and potentially restoring it if needed). PS - embarrassed to realize we had forgotten to remove Feature freeze from the Baggage API and Context documents.
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?
Should the changelog be updated to include this change?
Signed-off-by: Juraci Paixão Kröhling [email protected]