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. 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. 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, 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. James Sent from Google Mail for mobile On 6/29/08, Rene Rivera <grafikrobot@gmail.com> wrote:
Daryle Walker wrote:
Here's an idea on how we can manage our source-control for releases:
1. When we're ready to start a new release, make a branch from the trunk with a name like release_1_??_x (e.g. "release_1_37_x")
Why? What do we gain from having the release branch tagged with the version? Why branch from trunk? And there are various drawbacks, some of which where raised the last time we discussed this:
* It means testing process needs to change to switch to a new branch at the start of each release. This is currently a *manual* activity which needs coordination from many people.
* It makes it harder to track changes across releases since we have to backtrack through copies of loosely related source trees.
* It makes it harder to stabilize the code for release since the trunk will have many more unstable changes. This is the *key* reason we switched from basing releases on trunk. And without this change a release every 3 months is impossible.
2. Finalize what needs to be done to make that branch ship-worthy 3. Make a tag from that branch with a name like release_1_??_0 (e.g. "release_1_37_0") 4. Export that tag to a fresh directory and create the appropriate archive file to upload to SourceForge, etc. (The directory shouldn't have any source-control debris in it. Maybe this needs to be done once on each platform to ensure the best archive format and the proper line-ending markers.)
We already do that.
5. If bug-fixes for that release need to be done, continue to use the release_1_??_x branch (and merge the fixes back to the trunk, or vice versa)
If a bug fix release is needed a branch can be created from the release_x_yy_z tag at any time. And it can follow the usual merge of patches and release procedures. Once that patch release is tagged and released the corresponding branch can be deleted, and the next patch for that release can start again from the appropriate tag.
-- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- Sent from Google Mail for mobile | mobile.google.com