Clarify our stance re: release candidates (#8975)

Clarifies our stance regarding RC releases, inspired by
#8935 (comment).
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 <a9@aneurysm9.com>

.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.

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