[docs, .github] Add new issue template for stabilizing a module #8935
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,24 @@ | ||
| --- | ||
| name: Module stabilization | ||
| about: Stabilize a module before a 1.0 release | ||
| title: 'Stabilize module X' | ||
| labels: 'stabilization' | ||
| assignees: '' | ||
| --- | ||
|
|
||
| Before stabilizing a module, an approver or maintainer must make sure that the following criteria are met: | ||
|
|
||
| - [ ] One RC release or more have been done of this module | ||
| - [ ] No open issues or PRs in the module that would require breaking changes | ||
| - [ ] No TODOs in the module code that would require breaking changes | ||
| - [ ] No deprecated symbols in the module | ||
| - [ ] No symbols marked as experimental in the module | ||
|
There was a problem hiding this comment. Curious why? Seems common for stable module to have experimental APIs, e.g. grpc-go. There was a problem hiding this comment. We discussed a bit about this on #4705 and #4832. Personally, I think grpc-go's approach has caused a lot of pain to end-users; I gathered some issues related to it on #4832 (comment). We also have the experience of opentelemetry-go, where their decision to have interfaces that can change across minor versions has caused some pain (see open-telemetry/opentelemetry-go/issues/3277) We can discuss this more explicitly (I think having a more explicit guideline as to how to implement experimental methods is important), but for now I think requiring the 1.0 version to not have experimental symbols is not too onerous There was a problem hiding this comment. Thanks for the context, I agree the implication of experimental APIs can be a separate discussion. Makes sense to me to not have them for 1.0 to begin with (since relaxing this constraint in the future is feasible). |
||
| - [ ] The module follows the [Coding guidelines](https://github.com/open-telemetry/opentelemetry-collector/blob/main/CONTRIBUTING.md) | ||
|
|
||
| Please also make sure to publicly announce our intent to stabilize the module on: | ||
|
|
||
| - [ ] The #otel-collector CNCF Slack Channel | ||
| - [ ] The #opentelemetry CNCF Slack channel | ||
| - [ ] A Collector SIG meeting (if unable to attend, just add to the agenda) | ||
|
|
||
| To help other people verify the above criteria, please link to an RC release, the announcement and other links used to complete the above in a comment on this issue. | ||
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.
Do we want to do rc releases going forward, given the reported issues?
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 doing one or two RC releases makes sense, but I agree that definitely 18 RC releases is too much 😄 We can add some guidance to this document as part of solving #8063 (something like "if we do more than two RCs go back to minor versions until we solve the issue(s) in question")
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.
Maybe we can just require two 0.x versions with all other checkboxes marked instead of jumping back and forth to RC
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.
unless there's a strong argument for a RC tag, i would agree that we could call a package out as RC as of version 0.x and avoid unnecessary process and pain