[1.32 release] Branch for release postponed -- Plea for help

Branch for release scheduled for today, July 16, will NOT be performed. The two main showstoppers are an unsatisfactory state of the main trunk (http://tinyurl.com/25ar3) and a further delayed MPL check-in. It's going to take at least a couple more days for me to deal with the latter, and it would be really appreciated if during that time somebody would volunteer to work on clearing up the regression picture; the more volunteers, the better! Many library maintainers are already doing a good job at it, but the previous experience shows that whole thing can be made significantly more efficient if people who have local access to particular compilers failing on particular libraries [of their interest] took a look at those failures and reported back the results of their finding/posted patches/ checked in fixes. If each of us with a little bit of familiarity with the codebase/free time on their hands would take care of only a single failure, it would already make an enormous difference. Needless to say, everyone who contributes to this is going to be acknowledged when the release is out. (And a warm "thank you" to everybody who is already investing their time and energy into this!) -- Aleksey Gurtovoy MetaCommunications Engineering

Branch for release scheduled for today, July 16, will NOT be performed. The two main showstoppers are an unsatisfactory state of the main trunk (http://tinyurl.com/25ar3) and a further delayed MPL check-in.
There's something else we need to do as well - update the Boost version number everywhere - dealing with boost/version.hpp is easy enough, but what has to change in the Build system? John.

"John Maddock" <john@johnmaddock.co.uk> writes:
Branch for release scheduled for today, July 16, will NOT be performed. The two main showstoppers are an unsatisfactory state of the main trunk (http://tinyurl.com/25ar3) and a further delayed MPL check-in.
There's something else we need to do as well - update the Boost version number everywhere - dealing with boost/version.hpp is easy enough, but what has to change in the Build system?
I dunno. Rene? Shouldn't we write this stuff down in more/release_procedures.htm? -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

David Abrahams wrote:
"John Maddock" <john@johnmaddock.co.uk> writes:
There's something else we need to do as well - update the Boost version number everywhere - dealing with boost/version.hpp is easy enough, but what has to change in the Build system?
I dunno. Rene?
The version used by the build system is in boost-root/Jamrules.
Shouldn't we write this stuff down in more/release_procedures.htm?
I thought Beman had done that? -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq

Rene Rivera wrote:
David Abrahams wrote:
Shouldn't we write this stuff down in more/release_procedures.htm?
I thought Beman had done that?
PS. He did. It's in the "Release Manager's Checklist" (more/release_mgr_checklist.html) -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq
participants (4)
-
Aleksey Gurtovoy
-
David Abrahams
-
John Maddock
-
Rene Rivera