From: Daryle Walker (darylew_at_[hidden])
Date: 2008-07-12 03:29:48
Based on reading the various posts on releasing Boost 1.36....
Maybe we should promote the idea that the trunk of our Subversion
repository should be as stable as possible as an official policy. I
think a lot of open source projects do this; because it brings a big
benefit: fast turn-around times for releases. With a stable trunk,
the release manager makes a branch for release from the trunk, has
everyone help in testing and making sure the branch is otherwise
fully stable, then ship out the final version of that branch. After
that, the changes on that branch have to be merged into the trunk to
make it more stable. (And the branch can be removed.) Realize that
the release branch preparation is _only_ for stabilization (i.e.
bugs); anyone who was late for adding a new OR revised feature has to
wait for the next release cycle.
I think we're trying to do releases every three months, here's a
1. For the first two months, we're just updating the trunk with bug-
fixes, revised features, and new features/libraries. Bug-fix
releases come out during this time as needed. Any fix has to be
based on a commit on the trunk. The bug release manager just makes a
branch off the last bug release tag (or the last major release tag if
we're doing the first bug release) and applies the selected bug fix
change-sets, then ships after the group's testing. (The branch is re-
merged then removed.) The release team would (generally) do the bug-
fix incorporation; the libraries' developers did their parts by
adding the fixes in the trunk in distinct change-sets. Hopefully,
this would take a week for branching and fix-merging, then another
week or so for testing.
2. Work on the trunk has to be kept stable. Incorporate changes
into the trunk in distinct steps that do not break the build. Huge
changes, like ones that could cause merge & conflict hell, especially
if done during release time, should be kept on a branch until ready
to be incorporated. Branchers should keep their branch current with
the trunk as far as unrelated files (and pieces of related files) are
concerned. (Alternatively, if a big change can be broken into steps
that individually don't break the build, then that should work too.)
Note when a distinct step is committed, it's not just code; the
corresponding documentation and tests for that step need to go in too.
3. For the last month, work on the next major release begins. If we
follow the always-stable-trunk ideal, then this will be like case
. We pick a deadline. On the deadline day, the release manager
branches off the trunk on the most stable revision around that time.
There's a week-long period where incomplete big changes either need
to be finished to an acceptable cut-off (which may be 100% if it was
nearly done) or get back-tracked to a previous acceptable cut-off.
The release team and the library developer discuss which focused
revision the cut-off will be cherry-picked from (either backward or
forward). The remainder of the procedure happens like , probably
even to the point of the short completion times (1 to 2 weeks).
4. The branches here are transitory. They should be created as
needed and removed when they're not necessary. The major release
branch would be called "release" and the bug fix branch called "bug-
release". They may be around simultaneously. There should be a
special branch called "hotness" (or whatever) that is an alias to the
"trunk" most of the time, but to "release" or "bug-release" when
those branches exist. (If both exist, "bug-release" takes priority;
but bug releases have to be quick so the release isn't bogged down.)
Our test crew can just park on "hotness" and make sure to update and
test regularly, preferably on automatic. The branch points will be
tagged ("1_37_origin", "1_37_0", "1_37_1", "1_38_origin", etc.) so we
don't forget them, of course.
-- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com