Mark opentelemetry-proto repo 1.0 #456
Comments
|
@open-telemetry/specs-approvers please add any other items to the checklist above that you think are needed before we mark this repo 1.0. |
We merged the open-telemetry#432 without clarifying when exactly the guarantees start applying. The intent was that the guarantees are needed for 1.0 release but we didn't make this explicit. We are now making this explicit and until 1.0 released we should be free to fix the remaining known issues listed here: open-telemetry#456 Once 1.0 release is made we can remove the [from 1.0.0] labels from the README.md.
We merged the #432 without clarifying when exactly the guarantees start applying. The intent was that the guarantees are needed for 1.0 release but we didn't make this explicit. We are now making this explicit and until 1.0 released we should be free to fix the remaining known issues listed here: #456 Once 1.0 release is made we can remove the [from 1.0.0] labels from the README.md.
|
Please consider to add a VERSION file as well, per issue #434 (Not a spec approver, this is just a suggestion) |
|
@open-telemetry/specs-approvers I went over the list of open issues and do not see anything else that can block the 1.0 that is not already on our checklist. If you think otherwise, please add to the list. |
|
@tigrannajaryan I think we are ready to go (I mentioned this in this week's Spec call, and I see no further comments). |
|
We are ready. I suggest releasing OTLP 0.20.0 now, then release 1.0.0 in 2 weeks to give time to notice any issues. |
|
@open-telemetry/specs-approvers I prepared the draft release 1.0.0: https://github.com/open-telemetry/opentelemetry-proto/releases/tag/untagged-c53594e61f023c410cc4 Is there anything that needs to be changed in this repo before we hit the release button? |
|
One small comment related to this, is how are we going to allow adding of new signals after 1.0? Since we have these guarantees, any new signal is automatically stable? Are we going to have multiple versions? Would be good to understand that path for that, since there will be folks commenting that if we include that new signal in 1.0 you need to have it stable from the first release.. |
|
Good questions!
No. We have a maturity table where signals are explicitly listed: https://github.com/open-telemetry/opentelemetry-proto#maturity-level When adding a new signal we must also add a row in this table. New signals will get added as "Alpha" and then will mature over time.
No, I think we should stay on 1.0 for now. OTLP 2.0 will be either for breaking changes or when we want to add something so big that even though it does not break existing stuff we want to increase the major version number. @open-telemetry/specs-approvers Do we feel that any of these needs to be recorded as a text in the README or in docs sub-directory and not just as a comment in this issue? |
|
I would like just a short sentence that the 1.0 artifact may include unstable/alpha components that can break |
@bogdandrutu see PR: #489 |
|
#489 is merged. Last call before 1.0.0 goes out. |
|
@tigrannajaryan one more "nit" #490 |
|
I think we are ready now, at least I have no more objections |
|
Please fix the CHANGELOG. It reads: Expected: |
…metry#467) We merged the open-telemetry#432 without clarifying when exactly the guarantees start applying. The intent was that the guarantees are needed for 1.0 release but we didn't make this explicit. We are now making this explicit and until 1.0 released we should be free to fix the remaining known issues listed here: open-telemetry#456 Once 1.0 release is made we can remove the [from 1.0.0] labels from the README.md.
…metry#467) We merged the open-telemetry#432 without clarifying when exactly the guarantees start applying. The intent was that the guarantees are needed for 1.0 release but we didn't make this explicit. We are now making this explicit and until 1.0 released we should be free to fix the remaining known issues listed here: open-telemetry#456 Once 1.0 release is made we can remove the [from 1.0.0] labels from the README.md.
…metry#467) We merged the open-telemetry#432 without clarifying when exactly the guarantees start applying. The intent was that the guarantees are needed for 1.0 release but we didn't make this explicit. We are now making this explicit and until 1.0 released we should be free to fix the remaining known issues listed here: open-telemetry#456 Once 1.0 release is made we can remove the [from 1.0.0] labels from the README.md.
…metry#467) We merged the open-telemetry#432 without clarifying when exactly the guarantees start applying. The intent was that the guarantees are needed for 1.0 release but we didn't make this explicit. We are now making this explicit and until 1.0 released we should be free to fix the remaining known issues listed here: open-telemetry#456 Once 1.0 release is made we can remove the [from 1.0.0] labels from the README.md.
This is the checklist we want to go through before marking this repo 1.0.
All issues must be resolved, PRs must be merged or closed. Please add any items you think are missing to this list.
The text was updated successfully, but these errors were encountered: