From: John Maddock (john_at_[hidden])
Date: 2004-08-27 05:06:03
> 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
> 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.
Normally that would work, but since the next MPL *has* to be released inside
the next month (for the book deadline), there is no way we can get two
releases out in that time IMO.
I think we're just going to have to patient for a week or two.
> 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
> Actually, all boost libraries - including an MPL update, should take this
Ideally yes, I think the next release should be schedule-based rather than
feature based; this release and the lat one were essentially delayed because
they were feature based and sometimes things just take longer than you
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk