From 2914a537dbad960839acf923f369d6b00733e4af Mon Sep 17 00:00:00 2001 From: Frederic Branczyk Date: Thu, 4 Jul 2019 15:18:39 +0200 Subject: [PATCH 1/2] RELEASE.md: Add procedure for when to publish docs Signed-off-by: Frederic Branczyk --- RELEASE.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/RELEASE.md b/RELEASE.md index 3f86b86df..04fe497de 100644 --- a/RELEASE.md +++ b/RELEASE.md @@ -88,9 +88,9 @@ Now all you can do is to wait for tarballs to be uploaded to the Github release If the release has happened in the latest release branch, merge the changes into master. -To update the docs, a PR needs to be created to `prometheus/docs`. See [this PR](https://github.com/prometheus/docs/pull/952/files) for inspiration. +To update the docs, a PR needs to be created to `prometheus/docs`. See [this PR](https://github.com/prometheus/docs/pull/952/files) for inspiration (note: only actually merge this for final releases, not for pre-releases like a release candidate). -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. +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. ### Pre-releases From ac7b0ae4e6a7e9e5c9eae90f16d393a78a1fea77 Mon Sep 17 00:00:00 2001 From: Frederic Branczyk Date: Thu, 4 Jul 2019 15:47:32 +0200 Subject: [PATCH 2/2] RELEASE.md: Add command to run benchmark on release candidates Signed-off-by: Frederic Branczyk --- RELEASE.md | 1 + 1 file changed, 1 insertion(+) diff --git a/RELEASE.md b/RELEASE.md index 04fe497de..3c1917ba8 100644 --- a/RELEASE.md +++ b/RELEASE.md @@ -99,4 +99,5 @@ The following changes to the above procedures apply: * In line with [Semantic Versioning](https://semver.org/), append something like `-rc.0` to the version (with the corresponding changes to the tag name, the release name etc.). * Tick the _This is a pre-release_ box when drafting the release in the Github UI. * Still update `CHANGELOG.md`, but when you cut the final release later, merge all the changes from the pre-releases into the one final update. +* Run the benchmark for 3 days using the `/benchmark x.y.z` command, `x.y.z` being the latest stable patch release of the previous minor release series.