From: Jeff Garland (jeff_at_[hidden])
Date: 2004-02-11 20:05:32
On Wed, 11 Feb 2004 17:20:36 -0500, Beman Dawes wrote
> At 11:16 AM 2/11/2004, David Abrahams wrote:
> >> If fixes aren't forthcoming for libraries that many other Boost
> >> libraries depend on, it delays testing on the other libraries.
> >Was that really a factor in this last release? Which libraries
> were >delayed, and which fixes weren't forthcoming?
> Iterator adaptors and type traits hurt a lot when they break.
> Sometimes it takes awhile to figure out exactly what the problem is,
> too. For example, a change around January 16 caused VC++6.0 to ICE
> on several libraries. It didn't get fixed until the 26th, because it
> took time to realize where the fault lay. IIRC, it got fixed the
> same day once we had figured out what change actually triggered the
> failure. Earlier in the release cycle, it took a while to get the
> auto link stuff working on all compilers. The release manager can
> only focus on so many things at once.
To me the autolink thing was sort of an 'unplanned feature' for the release.
I don't recall seeing any warning or discussion about it until we were just
putting it in. Now, mind you John really did most of the work, which I
appreciate greatly, but in my mind we should have left it out for this
release because it is too destabalizing a change after the branch for release.
In fact, right now is the time for destabalizing features to go in. I
believe we have a couple new libraries to add, etc. In a couple months we
ought to call a halt to all this sort of destabalizing change on the main
branch. If people have exploritory changes they can move off to a
development branch, or we can branch for release and stabalize it, and let
the destabalizing change go on main. And that's the other key, once we
branch for release feature development has to stop on the release candidate --
bug fixes only....I thought that was the policy, but it didn't happen that
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk