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

From: Christian Larsen (contact_at_[hidden])
Date: 2008-08-20 14:19:38

>> 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.

Once there are enough bugfixes in "branches/boost_1_37", it may be 
decided to release an updated version of 1.37. So we just create a new 
tag, "tags/boost_1_37_1", from "branches/boost_1_37", and make a release 
from that copy. We can rest assured that all the bugfixes from that 
release are still in trunk, because that's where they originate from.

Development goes on for some time in trunk, and relevant bugfixes are 
merged to the release branch. Until at some point it is decided to 
release 1.38. Same procdedure as last time: Make a new branch 
"branches/boost_1_38" as a copy of trunk, and create a tag 
"tags/boost_1_38_0" from that new branch.

Now bugfixes in made in trunk go into the new release branch 
"branches/boost_1_38". At your option also to older release branches to 
keep the old version up to date for users that don't want to/can't upgrade.

I see many benefits from this approach as many things come for free, and 
it requires little work from all involved. The only important thing 
developers must remember, is that all new features/interface breaking 
changes go to trunk, and bugs are fixed in trunk, then merged into the 
release branch(es).

AFAIK new versions of Subversion even helps manage this merging 
nightmare by automatically keeping track of exactly which revisions from 
e.g. trunk are merged into each of the other branches. You might want to 
look into that feature. If an older version of Subversion is used (pre 
1.5 I think), then a tool such as svnmerge might help.

Just my 2 cents, and as I'm not a Boost developer it doesn't affect me 
that much, but of course I would like to see regular and stable releases. ;)

Best regards,
Christian Larsen