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