From: Douglas Gregor (doug.gregor_at_[hidden])
Date: 2007-05-04 09:38:52
On Wed, 2007-05-02 at 18:30 -0400, Beman Dawes wrote:
> That isn't at all what I had in mind. Rather, a release, say 1.35 would
> start with the previous release - 1.34 in this case. Developers, who
> have been working in devel (which is equivalent to the old HEAD),
> branch/tag their code at the point they think it is OK as "stable". Then
> when it comes time to do a release a script run by the release manager
> tries to merge code for the library from "stable" to the release
> candidate branch (working in library dependency order, with cycles
> broken when necessary).
I'm a bit confused... is "stable" a branch, or just a way to refer to
certain points in the development of a library?
> Tests are run. If there are failures, the script
> reverts the broken library, and moves on. We might do something like
> give developers a fixed period of time (a week? 10 days?) to fix
> "stable", but when the merge/test/revert-if-needed script is run again,
> any libraries that are still failing don't make it into the current release.
I'm very skeptical of any process that depends on an automatic
merge/revert script. Such a script will require a huge amount of effort
to develop and maintain (particularly because it needs dependency
information) and is going to require intervention for non-trivial merge
Anyway, I should wait until I read your proposal before commenting
further. I don't think we should wait until 1.34.0 is out the door
before discussing the proposal, because once 1.34.0 is out there I'd
like to switch to Subversion shortly thereafter, and the Subversion
layout should reflect our updated process.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk