[Releasing] rethinking the branching scheme
oswald.buddenhagen at digia.com
Wed Feb 19 12:47:01 CET 2014
you may remember that we arrived at the dev/stable/release scheme after
a some lengthly discussion a few years back.
now i'll explain that imo that scheme failed, and that we need to go
back to a more traditional one. hurray!
the crucial issue is - surprise surprise - the CI system:
- a straight downmerge just doesn't work due to the reverse
this can be temporarily disabled, but that is a hassle. also, even
when we tried that, things were a huge mess.
- the workaround is doing a forward merge and then direct-pushing a
for this to work, the target branch needs to be locked down for a day
or two. that alone is obviously quite a disruption for people not
involved in the release process.
another lesson from today's experience is that despite fairly heavy
restrictions as to who can stage, we *still* got three "rogue" commits
in qtbase/stable today from people who happened to have the rights,
but were not involved in the release process this time. locking this
down even further, tailored to the particular situation each time
around, would be hassle (and thus error-prone).
so it basically comes down to non-atomicity, exacerbated by the enormous
the answer to that is quite obviously using an operation that is
naturally atomic: branch creation.
on top of that, we already realized that we need the old/ branch
namespace to be able to release from older versions (in case of security
fixes). this is quite a hassle to maintain as well, and the asymmetry
makes things hard to understand (and virtually impossible to actually
so i'm proposing that we switch to a master/5.x/5.x.y scheme as we had
before opengov (and as we still have for qt creator).
the implications are, afaict:
- we solve the downmerge problem ... by not having it in the first
place. only forward merges and branch creations.
the biggest advantage here is that branching can be done very quickly
in a uniform process by somebody from the release team, without
coordinating every step with half a dozen people.
- CI configs will need to be cloned for each new branch. we need to make
sure that this is reasonably low-hassle.
- one of the strong arguments for the current scheme was the purported
simplicity for the developers.
i think experience shows that this didn't really work out:
- the branches still have phases (e.g., "soft freeze" right after a
- people think in release versions anyway
- the "missed the deadline and need to cherry-pick" scenario continued
to exist, and was actually made much worse due to the fuzziness of
the date (again the CI delays). that's why we now have the staging
lockdowns on the *source* branches (i.e. dev around the dev =>
with the traditional scheme:
- people will need to figure out what "stable" is. no biggie - they
really do that anyway (in the other direction).
- pushing to a too high branch will still be prevented by the
staging lockdown for around two days
- pushing to a too low branch is no big deal, as we'll just forward
merge. at some point we'll lock down old branches, too (we
actually did that in the pre-opengov times)
- making anything but master the default git branch will be
unrealistic (we can't script updating gitorious and github). i don't
think that is a big deal.
- i can retroactively create/move the branches for previous releases
- we need a new picture for http://qt-project.org/wiki/Branch-Guidelines ;)
everybody on irc involved in the current disaster^Wrelease was in favor
of giving this some serious consideration.
More information about the Releasing