From f349a1b0f5fb9f1c9c0fdca666b80ec4a55b773b Mon Sep 17 00:00:00 2001 From: Pablo Baeyens Date: Wed, 22 Nov 2023 18:28:16 +0100 Subject: [PATCH] Clarify our stance re: release candidates (#8975) Clarifies our stance regarding RC releases, inspired by https://github.com/open-telemetry/opentelemetry-collector/pull/8935#discussion_r1397887303. In a nutshell: - Stabilization criteria have to be met for at least two minor version releases before moving to the stable module. - We treat these two (or more) minor releases as release candidates and do not release under the `-rc` release family. - After these releases, we move directly to the `1.x` release family. **Link to tracking Issue:** Fixes #8063 (together with the upcoming 1.0 release for pdata and featuregate) cc @braydonk --------- Co-authored-by: Anthony Mirabella --- .github/ISSUE_TEMPLATE/stabilization.md | 7 ++++--- docs/release.md | 4 +++- 2 files changed, 7 insertions(+), 4 deletions(-) diff --git a/.github/ISSUE_TEMPLATE/stabilization.md b/.github/ISSUE_TEMPLATE/stabilization.md index be39d8a3f13..bd6d9802bcb 100644 --- a/.github/ISSUE_TEMPLATE/stabilization.md +++ b/.github/ISSUE_TEMPLATE/stabilization.md @@ -6,9 +6,8 @@ labels: 'stabilization' assignees: '' --- -Before stabilizing a module, an approver or maintainer must make sure that the following criteria are met: +Before stabilizing a module, an approver or maintainer must make sure that the following criteria have been met for at least two successive minor version releases: -- [ ] 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 @@ -21,4 +20,6 @@ Please also make sure to publicly announce our intent to stabilize the module on - [ ] 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. +To help other people verify the above criteria, please link to the announcement and other links used to complete the above in a comment on this issue. + +Once all criteria are met, close this issue by moving this module to the `stable` module set. diff --git a/docs/release.md b/docs/release.md index a964b97b79d..d83d01987d6 100644 --- a/docs/release.md +++ b/docs/release.md @@ -143,7 +143,9 @@ The following documents the procedure to release a bugfix ## 1.0 release -Stable modules adhere to our [versioning document guarantees](../VERSIONING.md), so we need to be careful before releasing. Before adding a module to the stable module set and making a first 1.0 release, please [open a new stabilization issue](https://github.com/open-telemetry/opentelemetry-collector/issues/new/choose) and follow the instructions in the issue template. +Stable modules adhere to our [versioning document guarantees](../VERSIONING.md), so we need to be careful before releasing. Before adding a module to the stable module set and making a first 1.x release, please [open a new stabilization issue](https://github.com/open-telemetry/opentelemetry-collector/issues/new/choose) and follow the instructions in the issue template. + +Once a module is ready to be released under the `1.x` version scheme, file a PR to move the module to the `stable` module set and remove it from the `beta` module set. Note that we do not make `v1.x.y-rc.z` style releases for new stable modules; we instead treat the last two beta minor releases as release candidates and the module moves directly from the `0.x` to the `1.x` release series. ## Release schedule