Boost logo

Boost :

From: Robert Ramey (ramey_at_[hidden])
Date: 2004-06-29 00:05:31


Last time we ended up making a release candidate which isolated a couple of
final issues. Maybe this is a symptom and maybe it points in the direction
of an interesting idea.

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.

I realize that I haven't personally had a library go through the release
process so feel free to ignore this idea.

Robert Ramey


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk