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.
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 release"
Actually, all boost libraries - including an MPL update, should take this approach.
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 expect :-( John.