release_process: please clarify versions
If there should be a single issue I faced during the 3.13 release process, this is the one.
There are a fair number of assumptions in
including the rhythm of major and bugfix releases. At least: one is
expected to know about the next major release, and about the one after
that! Which isn’t the case right now, as we have a number of bugfix
releases in a row, followed by a major release which has an unknown
version number (3.17 or 4.0). Admittedly, this could be called a corner
case, but it’s bound to be repeated for at least 3.14, and maybe 3.15,
depending how far ahead scheduling (major) releases is going to happen.
I’ve tried to adapt as best as I could the instructions so they would make sense, targetting the next two releases (3.14 and 3.15, both bugfix); I’ve also opened #16572 (closed) and asked another RM to look at it urgently (again, thanks for the swift answer) to make sure what I was doing wasn’t entirely crazy. I didn’t read all the reply (#16572 (comment 11386)) and stopped at “tl;dr: for 3.13, go for what you did already; for next time, read what follows.” and a similar “it’s fine, carry on” on XMPP.
But the next day, I tried to follow the post-release steps (which for
various organisational reasons I managed to dodge most times until now…)
3.17 as the next major version in the
devel branch, which I’m
told would break the test suite.
I find it very hard to:
- decide what should be set through various environment variables. This has gotten better with the great MAJOR vs. BUGFIX renaming/clarification rounds though. But that started with some kind of cargo-culting, copying and pasting the RM’s file for the previous release, and trying to guess what should be bumped.
- understand all the implications of specifying this or that version at a given step. While this might be OK if one were able to follow the release process documentation blindly, experience for all RMing iterations I’ve taken part in shows that there are always exceptions and deviations that one should be prepared to operate.
Therefore, I would very much welcome some kind of “definitive guide to versions” that would help RMs remember everything there is to know about versions/branches/etc.; or at the very least, help RMs operate consistent choices when they have to deviate from the release process documentation.
Again, looking at previous release cycles, there are always many things to prepare on release day 1, the release itself to publish on day 2 (usually waiting on the MFSAs, so we cannot expect to finish everything on that day, even for a night owl like me), and post-release steps. Given how busy days 1 and 2 are, even with more experience, I don’t think I’ll ever manage to get post-release steps done before day 3. And keeping a train of thoughts over 3 days doesn’t seem realistic, at least to me (e.g. if I had read and understood the last part of #16572 (comment 11386) on day 1, I wouldn’t have thought about it and anticipated all the consequences, when performing post-release steps on day 3).
Feature Branch: master