-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
Add support and stability level definitions #9412
Add support and stability level definitions #9412
Conversation
I believe I addressed all comments, but there are some discussions pending. |
Just to make it explicit how I see the lifecycle of a component to be, which would justify the need for only three stability levels:
As a user, I'm not sure I see the need for the second stage to be broken down into other stages: the information I need is only whether the component I need is ready for production or not. |
I tend to agree. Though if the code owners want to breakdown the Experimental stage into more granular levels within their README somewhere else I think that is ok, as long as it is also marked Experimental in all expected places (top of README, any tables somewhere, etc). |
6a71366
to
c7e6936
Compare
Reading through the change from Experimental to Alpha/Beta I actually think I've changed my mind. Alpha and Beta are well defined and Stable is still the indicator that "yes, this is good to use in production". As a customer (especially if I am an early adopter) Alpha and Beta will make it easier to decide which "Experimental" components I would feel comfortable using in production. When it was only "Experimental" I would probably have to dig deeper into the community/code to understand how risky it really is. |
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.
I left a comment on core distro wording but overall this LGTM
I applies some suggestions but forgot to publish the review comments :-) I have also applied @pmm-sumo's suggestion about the distributions/repositories. In any case, I think you all have seen the changes already, but I'll give it a few hours for folks to give it a final look. |
904c94c
to
0f8f867
Compare
README.md
Outdated
|
||
* **In development**: not all pieces of the component are in place yet and it might not be available as part of any distributions yet. Bugs and performance issues should be reported, but it is likely that the component owners might not give them much attention. Your feedback is still desired, especially when it comes to the user-experience (configuration options, component observability, technical implementation details, ...). Configuration options might break often depending on how things evolve. The component should not be used in production. | ||
* **Alpha**: the component is ready to be used for limited non-critical workloads and the authors of this component would welcome your feedback. Bugs and performance problems should be reported, but component owners might not work on them right away. The configuration options might change often without backwards compatibility guarantees. | ||
* **Beta**: same as Alpha, but the configuration options are deemed stable. While there might be breaking changes between releases, component owners should try to minimize them. |
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.
Didn't you propose that Beta can be used in production while config might break? #9412 (comment)
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.
I had only the config changes in mind based on previous comments, but we could say that people can have higher confidence in a beta component to run it with more workloads than they'd run with an alpha component. Let me draft something to that effect.
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.
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.
How about this?
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.
I think that wording is good. I like keeping "Stable" as the only place to official say "this is officially GA".
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.
Although now I'm wondering if instead of "Stable: the component is ready to be used in production." we should say something like "Stable: the component is ready for general availability." The former implies no stage before "Stable" should ever be used in production, but there are times Beta could be used, if you want to take some risk. The later implies this component has had a "production" release, thus making it safe to use.
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.
Makes sense to me
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.
PR updated.
Fixes #9379 Signed-off-by: Juraci Paixão Kröhling <[email protected]>
Signed-off-by: Juraci Paixão Kröhling <[email protected]>
Signed-off-by: Juraci Paixão Kröhling <[email protected]>
Signed-off-by: Juraci Paixão Kröhling <[email protected]>
Signed-off-by: Juraci Paixão Kröhling <[email protected]>
Co-authored-by: Przemek Maciolek <[email protected]>
Signed-off-by: Juraci Paixão Kröhling <[email protected]>
Signed-off-by: Juraci Paixão Kröhling <[email protected]>
4715eba
to
77c80a3
Compare
Looks like we have a good number approvals, so I'll go ahead and merge this. |
* Add support and stability level definitions Fixes open-telemetry#9379 Signed-off-by: Juraci Paixão Kröhling <[email protected]> * Addressed first round of comments Signed-off-by: Juraci Paixão Kröhling <[email protected]> * Second review round Signed-off-by: Juraci Paixão Kröhling <[email protected]> * Replace experimental with Alpha, added Beta Signed-off-by: Juraci Paixão Kröhling <[email protected]> * Replace other experimental instances with alpha Signed-off-by: Juraci Paixão Kröhling <[email protected]> * Apply suggestions from code review Co-authored-by: Przemek Maciolek <[email protected]> * Expand beta description, remove redundant paragraph Signed-off-by: Juraci Paixão Kröhling <[email protected]> * Use 'general availability' Signed-off-by: Juraci Paixão Kröhling <[email protected]> Co-authored-by: Przemek Maciolek <[email protected]>
Proposal for the definition of the stability and support levels. Once we have this in place, I'll add them to a couple of components to be used as example.
Notes:
Fixes #9379
Signed-off-by: Juraci Paixão Kröhling [email protected]