New code is checked in and tested in the development tree just as it is now. Regression testing and everything remains exactly as it is.

Code that documents all test failures and is considered ready for release is moved to the Release Candidate tree. The exact same regression testing setup used on the development tree is used here. Presumably, it would be run much less as things would only be checked in when thought to be perfect which is an infrequent occurrence.

Developers develop against the Release Candidate tree. When they have something they like, the check into the Main Development tree as they do now. Traffic on the main development tree is the same as it is now.

The Release Candidate Tree should be ready for "shipment" at any convenient time. This basically should consist of assignation of a version number to the tree state. It would not be or scheduled event dramatic event. It could happen as frequently as is convenient.

Of course a test failure on the RC tree would be dramatic event. The check in causing such an event could be cast from the RC Tree (Heaven) back into the Main Development Tree (Purgatory) and the author would suffer the attendant embarrassment. Hopefully this would be an infrequent event.

Actually I think this was suggested before, and there are two main issues as I see it: 1) Maintaining parallel development on two branches like that is a real pain in the you-know-where ;-) Performing the correct branch merge without endless conflicts to sort out afterwards is particularly tricky. 2) It consumes a lot of testing time for the regression testers - the tests already take a lot of processor / machine time to run, I'm not sure how the testers would view it if they were asked to test two parallel branches the whole time. Actually new development should already be done on a separate branch - I know that the mpl, regex and thread libraries have active branches on the go - and probably more libraries as well. The difficulty comes when it's time to merge and either: a) there's an API breaking change, and other libraries depend on your code. b) a bug on some obscure compiler to which the author has no access trips everything up. I guess this could be mitigated by authors publishing snapshots of changed code just prior to merge and asking for help with compilers for which they don't have access. But more importantly by having a clear "cut off time" for possibly breaking changes. I also think the main problem with the much delayed 1.31 release was that we had a desired feature-list-for-release rather than a firm schedule. Finally, since there seem to be several people who like me will just miss the 1.32 release, I think it's time to publish a provisional 1.33 schedule (see separate post). John.