From: Jeff Garland (jeff_at_[hidden])
Date: 2004-06-29 12:04:25
On Tue, 29 Jun 2004 12:04:30 -0400, David Abrahams wrote
> Not quite. With the branch, new code doesn't suddenly arrive and
> mess up test results for several days and cause various people to
> pull their hair out and scramble around looking for ways to port the
> test library code to untested platforms.
Agreed, but I'm assuming that step is already being taken...
> With the tag we'd have to decide whether to revert or not, etc., etc.
Yes, but it's an easy decision in my mind. If release schedule is put at risk
it gets backed out, period. But in my view it would be the release manager's
> Either the changes to the library should be made soon, IMO, or left
> off the main trunk until the release branch is made (and left off
> the release branch entirely).
Total agreement. My suggestion was a risk management strategy to give us an
option to back out more easily if something goes wrong.
Just as an aside, I agree with much of what you, Robert, and John were
observing about issues in past releases. In my view, most of the churn was a
result of last minute changes in existing libraries that have other
dependencies. Boost.Test was one, but there have been others (lexical_cast
comes to mind a couple releases back). Then there are boost wide changes like
the new dynamic library system that upset things in the last release as well.
I don't recall a in single release delay resulting from a new library
addition. So at some level I feel Robert is being too cautous with
serialization -- but I'm ok with waiting.
I think John's list of 'core libraries' was sensible. If we freeze changes in
those well in advance then things will be much smoother.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk