👋
I am happy to do next release. This is because we spent a lot time recent weeks in query optimizations on Prometheus, Thanos, and Cortex, so 2.18 release might have significant changes like:
* Chunk Iterators finally ❤️
* @pstibrany and @pracucci major optimizations to postings
* Potentially https://github.com/prometheus/prometheus/issues/6878 with @mkabischev help.
I know I was a release Shephard just in December, but given that I have full context for those I feel like I can help in releasing 2.18 a lot.
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>
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>
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>
