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
Not gonna happen, for reasons explained in
> 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
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk