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
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
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
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. ;)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk