From bab26d9df8cb8095d43f66b7cc0702a2dedb7672 Mon Sep 17 00:00:00 2001 From: beorn7 Date: Wed, 8 May 2019 13:30:35 +0200 Subject: [PATCH] Volunteer beorn7 as 2.10 release shepherd I'm willing to do this under the condition that I can run an experiment with never freezing master. See addition in the file. I believe, this way is more consistent with how we handle the bugfix releases after the final minor release is cut. It's at least worth a try. Signed-off-by: beorn7 --- RELEASE.md | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/RELEASE.md b/RELEASE.md index abc0eba066..b75094b0d1 100644 --- a/RELEASE.md +++ b/RELEASE.md @@ -6,7 +6,7 @@ This page describes the release process and the currently planned schedule for u Release cadence of first pre-releases being cut is 6 weeks. -| release series | date of first pre-release (year-month-day) | release shepherd | +| release series | date of first pre-release (year-month-day) | release shepherd | |----------------|--------------------------------------------|---------------------------------------------| | v2.4 | 2018-09-06 | Goutham Veeramachaneni (GitHub: @gouthamve) | | v2.5 | 2018-10-24 | Frederic Branczyk (GitHub: @brancz) | @@ -14,7 +14,8 @@ Release cadence of first pre-releases being cut is 6 weeks. | v2.7 | 2019-01-16 | Goutham Veeramachaneni (GitHub: @gouthamve) | | v2.8 | 2019-02-27 | Ganesh Vernekar (GitHub: @codesome) | | v2.9 | 2019-04-10 | Brian Brazil (GitHub: @brian-brazil) | -| v2.10 | 2019-05-22 | **searching for volunteer** | +| v2.10 | 2019-05-22 | Björn Rabenstein (GitHub: @beorn7) | +| v2.11 | 2019-07-03 | **searching for volunteer** | If you are interested in volunteering please create a pull request against the [prometheus/prometheus](https://github.com/prometheus/prometheus) repository and propose yourself for the release series of your choice. @@ -27,6 +28,8 @@ The release shepherd is responsible for the entire release series of a minor rel * Once a pre-release has been released, the `master` branch of the repository is frozen for any feature work, only critical bug fix work concerning the minor release is merged. * Pre-releases are done from `master`, after pre-releases are promoted to the stable release a `release-major.minor` branch is created. +_Experimental change of the above procedure for the v2.10 release: The `release-2.10` branch is created at the time the first pre-release is cut. All releases of the series including pre-releases are cut from the `release-2.10` branch. `master` will not be frozen for feature work._ + See the next section for details on cutting an individual release. ## How to cut an individual release