Boost logo

Boost :

From: David Abrahams (dave_at_[hidden])
Date: 2004-08-26 14:20:27


"Robert Ramey" <ramey_at_[hidden]> writes:

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

On what basis have you arrived at that conclusion? Have you been
following the progress of the new MPL work?

I hate to repeat myself, but:

   The CD for the book (which must contain a Boost release with the
   new MPL stuff) has to be final by early next month, and my
   assessment is that there's no possible way we can do two releases
   before then.

Therefore, the best bet is to do one release.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com

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