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