From: Robert Ramey (ramey_at_[hidden])
Date: 2004-08-25 23:57:49
Aleksey Gurtovoy wrote:
>JOAQUIN LOPEZ MU?Z writes:
>> I don't want to sound harsh or anything, and I truly appreciate the
>> effort that's being put in this, but a month has slipped by since the
>> first schedule for releasing, and AFAIK we don't even have an agreed
>> upon branching date for the near future.
>The branching date is pending MPL check-in. The latter has been postponed
>several times as the new issues surfaced (in particular, due to better
>tests), but it's crucial to ensure that the library is in the predictable
>state before the release (remember that it goes on the CD with the TMP
>book), so please bear with us.
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
> There are external constraints for this release's timeframe,
> but within those, the release is criteria-driven. One of the
> criteria is regression-free codebase,
This is criteria for release - not for branching
> and another is the new
> MPL version. There is no point of releasing "on time" if the
> release is useless.
Nothing in the current development tree - i.e. the 1.32 release candidate
depends on the MPL update that has yet to be integrated. There is no reason
to hold up branch/release for new features.
> Shouldn't we settle now on a realistic branching date
> and proceed with the release? Or, should I shut my mouth
> and let the release manager handle this as he deems
> Again, don't get me wrong. I am not willing to push
> anybody, but the process looks, well, erratic.
> Please don't forget that we are all volunteers here. The best
> way to speed up things is to contribute to them. MPL issues
> notwithstanding, we still have the regression field to be
> cleared --
> Turning it green while MPL is in works will make a huge
The only way an MPL update can be expected to not create new issues is it
makes only small changes. If that's the case its not worth holding things
up for. If the changes are not small, it likely will create a slew of new
>> If you are willing to take over managing that one
>> until the MPL check-in, be my guest.
I wish we could all do as well as Joaquin has been doing in clearing issues
related to his library. He has been doing an excellent job.
When this topic was discussed at the beginning of the release process, it
was indicated that subsequent releases would already be scheduled and would
be soon after 1.32 . This was to assure developers that if they missed this
release, it wouldn't be a big issue as the next one would be soon anyway.
This is still a good idea and should be implemented.
Release branch available only for bug fixes and test clearing
Main branch new MPL and what ever else.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk