Re: [boost] Re: 1.32 release prepar

From: John Maddock (john_at_[hidden])
Date: 2004-06-28 05:46:13

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