Commit graph

17 commits

Author SHA1 Message Date
Chris Marchbanks f9ae1a7c2f Add Chris Marchbanks as release shepherd for v2.14 (#5985)
Signed-off-by: Chris Marchbanks <csmarchbanks@gmail.com>
2019-09-04 18:35:15 +01:00
Frederic Branczyk ac7b0ae4e6
RELEASE.md: Add command to run benchmark on release candidates
Signed-off-by: Frederic Branczyk <fbranczyk@gmail.com>
2019-07-04 19:43:15 +02:00
Frederic Branczyk 2914a537db
RELEASE.md: Add procedure for when to publish docs
Signed-off-by: Frederic Branczyk <fbranczyk@gmail.com>
2019-07-04 19:42:59 +02:00
Simon Pasquier b3ecdd3f75 Bump promu to v0.5.0
It also includes an update of RELEASE.md since this version simplifies a
bit the release process: promu will take care of drafting the GitHub
release.

Signed-off-by: Simon Pasquier <spasquie@redhat.com>
2019-06-24 14:30:52 +02:00
beorn7 2e77b32fb5 Further clarification
Signed-off-by: beorn7 <beorn@grafana.com>
2019-06-05 19:51:17 +02:00
beorn7 1329faca14 Clarify when changes in master can be merged into the release branch
Signed-off-by: beorn7 <beorn@grafana.com>
2019-06-05 18:59:06 +02:00
beorn7 adfc5aaa64 Update instructions for the release shepherd
This codifies how 2.10 was released. It removes the inconsistency of
freezing master for pre-releases but handling post-release bug fixes
in a separate branch.

The previous instructions came from a time where master was often in
bad shape. However, that's a problem of its own, which should be
avoided at all times and not only when a release is imminent. On other
words, freezing master can still happen if it is in bad shape and we
need a break from feature development and just fix the bugs for a
while. However, it should not happen as a formal step during the
release of a release candidate. On the contrary, a release candidate
is not really a release candidate if we already know it is in such a
bad shape that we need bug fixes. On the other hand, if we truly
believe the RC could be identical to the final release, there is no
need to freeze master.

I can explain more of the concept if there is still a need for
clarification.

Signed-off-by: beorn7 <beorn@grafana.com>
2019-06-05 17:58:55 +02:00
beorn7 ac8d10f6e2 Replace Ganesh with Frederic for 2.11
Signed-off-by: beorn7 <beorn@grafana.com>
2019-06-05 15:22:49 +02:00
Julius Volz 1299a73781 Add next three release shepherds
Signed-off-by: Julius Volz <julius.volz@gmail.com>
2019-06-05 14:18:42 +02:00
beorn7 bab26d9df8 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 <bjoern@rabenste.in>
2019-05-08 13:30:35 +02:00
Björn Rabenstein 81acc1dc0f Update RELEASE.md to reflect mailing list change (#5472)
We are not using `prometheus-users@googlegroups.com` for announcments
anymore.

Signed-off-by: Bjoern Rabenstein <bjoern@rabenste.in>
2019-04-17 09:27:15 +01:00
Brian Brazil c8ee34d0b4 Put myself down for 2.9 release.
Update docs on where to email release announcements.

Signed-off-by: Brian Brazil <brian.brazil@robustperception.io>
2019-04-09 14:21:24 +01:00
Nguyen Van Duc 89d36a4bf6 Change http to https for security links (#5238)
Signed-off-by: vanduc95 <ducnguyenvan.bk@gmail.com>
2019-02-20 09:50:45 +00:00
Ganesh Vernekar ce69dcb0e5
Propose @codesome as 2.8 release shepherd
Signed-off-by: Ganesh Vernekar <cs15btech11018@iith.ac.in>
2019-02-11 23:44:01 +05:30
Goutham Veeramachaneni 834adc9566
Propose myself as the 2.7 shepard
Signed-off-by: Goutham Veeramachaneni <gouthamve@gmail.com>
2019-01-07 18:44:05 +05:30
Julius Volz 68f0787c37
Fix various misspellings of "shepherd" in the release docs (#5006)
Signed-off-by: Julius Volz <julius.volz@gmail.com>
2018-12-18 12:53:28 +01:00
Frederic Branczyk 3274a74595
Add RELEASE.md
Signed-off-by: Frederic Branczyk <fbranczyk@gmail.com>
2018-11-06 15:47:26 +01:00