Re:[boost] Re: [1.32 Plan] Stalled forever?

From: Robert Ramey (ramey_at_[hidden])
Date: 2004-08-26 12:22:19

>> The branch should occur now.  MPL update can go into the next release. 
>> Or you can see it a slightly different way.  Branch and release 1.32 now.
>> Rebranch and release 1.32 when MPL update has been added and any 
>> related issues resolved.

>Please be patient.

>Aleksey is having a hard time getting finished and the release date has
>slipped; it's true.  That said, the very existence of this release is due
>to our need to have a Boost release with an updated MPL for
>http://www.boost-consulting.com/mplbook.  The CD for the book has to be
>final by early next month, and there's no possible way we can do two
>releases before that time.  The schedule is getting increasingly tight; I
>just hope we can do _one_.

>I considered what would happen if we branched now and Aleksey integrated
>his changes into the release branch.  It seems apparent that it would only
>slow the release down further, since the changes would have to be
>integrated into the trunk, too.

This would be even worse than the current situation.

My real question was what is the downside of including MPL in release 1.33
rather than 1.32 ?  The important thing is the release date - not the
release number.  I believe that the rest of concentrating on a bug free
release of 1.32 while others get MPL ready for the NEXT release will result
in a sooner release date for the current library + MPL than otherwise.  So
my suggestion is:

Branch 1.32 rc now - make only bug fixes.  Actually at this point they
aren't really bugs so much as accommodation to different platforms, tool
configuration scripts. Etc.

Define 1.33 as 1.32 + new MPL and release it as soon as its ready - I would
envision this coming out a short time (4-8 weeks? - whatever) after 1.32. If
MPL slips in with no ripple effect - well no harm done.  If MPL ripples
through creating a bunch of new test failure, still no harm done, 1.32 is
still available.  This would in effect de-couple the release progress of the
boost library as a whole from any issues associated with a particular
library.

I didn't not think that I would be able to make the release for the
serialization library - indeed - I couldn't make the original one.  I was
prepared to work at my own pace and upload a "serialization add-in"
compatible with the latest release.  It would be then up to the manager of
the next to decide whether it was worthy to be included in the next "boost
release"

Actually, all boost libraries - including an MPL update, should take this
approach.

Robert Ramey