[boost] Suggestion: keep the trunk stable

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  
possible timeline:

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  
[1].  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 [1], 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