Re: [boost] A branching/tagging idea for releases

From: David Abrahams (dave_at_[hidden])
Date: 2008-06-29 20:55:27

James Sharpe wrote:
> What we gain is the ability to be making bug fix releases of previous
> versions whilst working on the next release. With the current system
> there is no way of doing this simultaneously, if we want a bug fix
> release, which I'd suggest should happen, given the demand we've seen
> on the list, we need a method of doing so.

I 100% agree with that.

> As far as testing, the issue of manually updating the builders could
> be dealt with by having a config file available on boost.org which
> specifies the svn path and configuration that should be tested.

Or much more simply, you can keep a directory called "release" that
simply contains an svn:externals reference to the current release
revision we're testing.

Of course, having testers operate on a single branch called "release,"
no matter how we do it, is really incompatible with the idea of testing
point releases concurrently with other releases.

> Updating the release testing group is then simply a matter of updating
> this one file centrally. Deficiencies in the testing scripts should
> not be a reason to disregard a particular release procedure if the
> deficiency can be addressed IMO.
>
> Also with regard to stabilising trunk,  I agree it won't be as easy,
> so instead maintain the current pratice and simply change the proposal
> to branch from the last stable release, thus giving the option of
> continuing to maintain the release on the same branch.
>
> As for tracking release history, try out some distributed version
> control systems, such as git or bzr, they make this kind of thing much
> easier, and I think that we should seriously be considering using
> them, 

Not gonna happen, for reasons explained in
http://lists.boost.org/Archives/boost/2005/09/92862.php

> this would mean we could get rid of the sandbox, since new
> libraries an simply be considered as branches from trunk, whih could
> have an enforced naming convention so it is clear they have yet to be
> accepted.

The sandbox is a place for people to collaborate among other things.  I
think svk handles all the things you want from git or bzr without
forcing us to change our repo, doesn't it?

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com