Re: [boost] [1.37.0] branches/release open for merges

From: Beman Dawes (bdawes_at_[hidden])
Date: 2008-08-26 12:43:53

Christian Larsen wrote:
>>> Shouldn't the final form of the release workspace be merged back into 
>>> the trunk (and then the branch [but not tag] deleted), and the next 
>>> version's workspace branched from the merged trunk?
>>
>> No. That's the "Wild West" system we used to use. It was a nightmare 
>> to manage. The new system is much better since branches/release stays 
>> much more stable, allowing us to get releases out quarterly.
> 
> The more I read about how you manage the repository, the more I wonder 
> why you don't do like most projects I have been working with. Maybe that 
> is what you are doing, but I can't get my head around it. ;)
> 
> What I'm used to is a trunk where general new development goes on 
> ("unstable" if you will, new features/libraries are added here). Then at 
> some point it is decided that a release with the current features in 
> trunk should be made. Let's call this release 1.37, so we copy trunk 
> into a release branch "branches/boost_1_37" or something like that. At 
> the same time we create a tag from this copy "tags/boost_1_37_0" and 
> make a release from that copy.
> 
> Now we have one tag, the frozen code used for release 1.37.0, and we 
> have two "branches" of development: "trunk" and the release branch 
> "branches/boost_1_37".
> 
> Now all bugfixes and new development go to trunk. *But* all bugfixes 
> that apply to the 1.37 branch as well are also merged to that branch! 
> This way we always have a "stable" branch ("branches/boost_1_37") with 
> no interface breaking changes, but all bugfixes applied. Users can 
> easily get what you've discussed as "hotfixes" by just checking out this 
> branch.

That's very similar to the process we used for years. The only real 
difference being that then we only tested on one branch at a time, so 
developers usually applied patches first to the release branch and then 
merged them back to trunk.

Getting a release out was a nightmare because it took so long to 
stabilize the release branch; it took close to a year.

In May, 2007, at BoostCon, four of the Boost moderators together with 
several other long-time Boost developers got together and at Jeff 
Garland's suggestion decided to base each release on the prior release 
rather than trunk. It took us awhile to get that process started, but 
now it seems to be functioning well, and is a day and night improvement 
over the old way of doing things.

Thus it is going to be a tough sell to get us to give up a process that 
seems to be working and revert to a process that was universally viewed 
as badly flawed.

--Beman