release: Extend instructions for the release shepherd

This adds the following:
- Find a new volunteer for the release shepherd if needed.
- Consider experimental features for promotion/demotion.

The latter could need more detailed explanation, but I guess we can
add those once we have the planned metrics for feature flags. For now,
I just wanted to have that point in so that it is not completely
forgotten.

Signed-off-by: beorn7 <beorn@grafana.com>

Co-authored-by: Levi Harrison <git@leviharrison.dev>
This commit is contained in:
beorn7 2022-01-04 17:12:30 +01:00
parent dfa5cb7462
commit 3be33de316

View File

@ -70,7 +70,7 @@ If a bug fix got accidentally merged into main after non-bug-fix changes in main
Maintaining the release branches for older minor releases happens on a best effort basis.
### 0. Updating dependencies
### 0. Updating dependencies and promoting/demoting experimental features
A few days before a major or minor release, consider updating the dependencies.
@ -85,6 +85,10 @@ you can skip the dependency update or only update select dependencies. In such a
case, you have to create an issue or pull request in the GitHub project for
later follow-up.
This is also a good time to consider any experimental features and feature
flags for promotion to stable or for deprecation or ultimately removal. Do any
of these in pull requests, one per feature.
#### Updating Go dependencies
```
@ -155,3 +159,5 @@ For release candidate versions (`v2.16.0-rc.0`), run the benchmark for 3 days us
If the release has happened in the latest release branch, merge the changes into main.
Once the binaries have been uploaded, announce the release on `prometheus-announce@googlegroups.com`. (Please do not use `prometheus-users@googlegroups.com` for announcements anymore.) Check out previous announcement mails for inspiration.
Finally, in case there is no release shepherd listed for the next release yet, find a volunteer.