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 cases. 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. - Doug