RFC: Creating release branches for each release
J. Paul Reed
comment on this proposal:
Hey all,
Rob Helmer and I have recently been discussing the release process as it
relates to tagging and retrieving source from the CVS repository for
Firefox and Thunderbird releases.
The way we do it now has a lot of historical vestiges and the policy was
crafted around some assumptions that aren't really valid for the project
and the way Firefox and Thunderbird (and other projects in the
Community) use the repository these days.
So we've come up with the following proposal we'd like feedback on.
The Proposal
============
When code complete is reached for the current Firefox release milestone,
a release branch will be cut. The standard FIREFOX_version_RC1 and
_RELEASE tags will be applied, but to a MOZILLA_datespec_RELBRANCH
branch that will replace the vernerable FIREFOX_version_MINIBRANCH. This
_RELBRANCH tag will be applied to the same files the _RC1 and _RELEASE
tags have been applied to.
If respins during the release are required, developers would check the
fixes into the relevant (1.8/1.8.0) branches, as always; they could then
either check the code into the _RELBRANCH themselves, or we can take
care of that, whichever is easier. When the code for the candidate is
ready, the next _RCn tag will be applied and the _RELEASE tag will be moved.
Rinse and repeat until the release is shipped.
Any equivalent Thunderbird release (if one is required) will come off of
this branch as well.
This branch will then die at the end of the release cycle.
This may be hard to visualize, so I took the liberty of adding it to our
beloved branching diagram (sorry in advance for the unwieldy size):
http://people.mozilla.com/~preed/bloggity-blog-blog/release-branch-proposal.jpg
The Reasoning
=============
Currently, we apply _RCn and _RELEASE tags to the relevant development
branch (i.e. MOZILLA_1_8_BRANCH) and then add _RCx tags and move the
_RELEASE tag as we respin candidates. This process must be undertaken
with extreme care, and while we record information when we perform the
operations against the repository, because CVS does not version tag
operations, that information is lost to external consumers of the source
coming out of CVS (this is why we tag the _RCs individually; to track
these changes).
Creating a release branch to isolate and record any changes required for
a specific release is a long standing release engineering best practice.
In the Mozilla Project's case, it will allow us to record the changes we
make during a particular release cycle and isolate changes so that we
are able to assert exactly what went into a release.
Additionally, it will make security firedrills significantly easier: the
release branch can be revived at any point in time to release a fix to a
particular security issue, so we can assert that a particularly release
is the previous release with *only* the required security changes, an
issue we've run in the past.
Finally, it will (admittedly, for me) simplify the release automation's
respin support; the automation can now just track the _RELBRANCH, as
opposed to attempting to fake branching by moving tags around on the
regular development _BRANCHes.
The Impact
==========
The impact to developers is quite low. In the worst case, those landing
post-code complete fixes (fixes to a release candidate) will have to
pull a branch to land their changes. In the best case (if a release
engineer merges the change, which is TBD, but quite possible), then
developers will not be impacted at all.
The impact to other projects relying on the Gecko milestone changes as
well as any other consumer of Firefox-related source code should
nonexistent; the _RCn and _RELEASE tags will, from an external
perspective, still exist and pulling them will do the "expected thing."
We have discussed, at some point, forgoing application of the _RELEASE
tag until a particular _RC is declared to be the final release, but this
would really only impact consumers of the source tarball who pick up the
RC tarball.
In terms of the repository, it is the case that one extra tag per
release will be applied to all the files; the _MINIBRANCH will be
replaced by the _RELBRANCH, so for the four files that were tagged with
the _MINIBRANCH, they will have the exact same number of tags.
The Upshot
==========
We're planning on implementing this change for the upcoming Firefox
2.0.0.4 release, so please discuss and let us know if you have any
questions or concerns.
Later,
preed
--
J. Paul Reed
Build/Release Engineer - The Mozilla Corporation
smtp://pr...@mozilla.com
irc://irc.mozilla.org/preed
pots://650.903.0800/x256