The Branches That Bind
(Crossposted1 to mozilla.dev.planning, mozilla.dev.builds, mozilla.dev.apps.camino, mozilla.dev.apps.calendar, mozilla.dev.apps.seamonkey, and mozilla.dev.apps.thunderbird).
rhelmer 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 venerable FIREFOX_version_MINIBRANCH. This _RELBRANCH tag will be applied to the same files the _RC1 and _RELEASE tags have traditionally 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 is why the suggested name is MOZILLA_datespec_RELBRANCH and not something like FIREFOX_version_BRANCH; products other than Firefox could come off the branch, and versions other than version could come off the branch.)
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:2
The Reasoning
Currently, we apply _RCn and _RELEASE tags to the relevant development branch (i.e. MOZILLA_1_8_BRANCH) and then add _RCn 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.
______________________________
1 Read: “spammed”
2 Sorry in advance for the unwieldy size.3
3 Click to enlarge!