[1.35.0] Merge for release complete.
The merge into branches/release "from" point was the 1.34.1 release. The "to" point was the trunk at revision 41356. This is very similar to a traditional *branch* for release. The effective difference is that a library can be easily reverted to 1.34.1. Hopefully, no libraries will have to be reverted. But we will do just that for any libraries not ready in the next ten days. The Unresolved Issues reports should now be reflecting the high-priority platforms the release managers will be using to make that determination. I'd like developers to hold off merging any changes since 41356 into branches/release until Friday. I'm going to be traveling until then and would like to be available for discussion as we open branches/release up for developer merging. Thanks, --Beman PS: The Windows smoke tests will be offline until late Thursday.
On Nov 26, 2007, at 8:24 AM, Beman Dawes wrote:
The merge into branches/release "from" point was the 1.34.1 release. The "to" point was the trunk at revision 41356.
This is very similar to a traditional *branch* for release. The effective difference is that a library can be easily reverted to 1.34.1.
Hopefully, no libraries will have to be reverted. But we will do just that for any libraries not ready in the next ten days. The Unresolved Issues reports should now be reflecting the high-priority platforms the release managers will be using to make that determination.
My nag scripts are still only nagging about unresolved issues on the trunk; shall I switch these over to the release branch, or perhaps send out nag e-mails for both trunk and release? - Doug
Doug Gregor wrote:
On Nov 26, 2007, at 8:24 AM, Beman Dawes wrote:
The merge into branches/release "from" point was the 1.34.1 release. The "to" point was the trunk at revision 41356.
This is very similar to a traditional *branch* for release. The effective difference is that a library can be easily reverted to 1.34.1.
Hopefully, no libraries will have to be reverted. But we will do just that for any libraries not ready in the next ten days. The Unresolved Issues reports should now be reflecting the high-priority platforms the release managers will be using to make that determination.
My nag scripts are still only nagging about unresolved issues on the trunk; shall I switch these over to the release branch, or perhaps send out nag e-mails for both trunk and release?
Good question. I hadn't really considered it before. My initial reaction is wait a couple of days to give developers a chance to merge any late fixes, then start nagging on both. Developers who still have failures outstanding really do deserve to be pestered at this point:-) Thanks, --Beman
on Mon Nov 26 2007, Beman Dawes <bdawes-AT-acm.org> wrote:
The merge into branches/release "from" point was the 1.34.1 release. The "to" point was the trunk at revision 41356.
This is very similar to a traditional *branch* for release. The effective difference is that a library can be easily reverted to 1.34.1.
Hopefully, no libraries will have to be reverted. But we will do just that for any libraries not ready in the next ten days. The Unresolved Issues reports should now be reflecting the high-priority platforms the release managers will be using to make that determination.
What does this mean for the SunPro workarounds I'm implementing that make Boost.Python work on that compiler? -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
David Abrahams wrote:
on Mon Nov 26 2007, Beman Dawes <bdawes-AT-acm.org> wrote:
The merge into branches/release "from" point was the 1.34.1 release. The "to" point was the trunk at revision 41356.
This is very similar to a traditional *branch* for release. The effective difference is that a library can be easily reverted to 1.34.1.
Hopefully, no libraries will have to be reverted. But we will do just that for any libraries not ready in the next ten days. The Unresolved Issues reports should now be reflecting the high-priority platforms the release managers will be using to make that determination.
What does this mean for the SunPro workarounds I'm implementing that make Boost.Python work on that compiler?
Go ahead and merge. See my post "[1.35.0] branches/release open for known-good merges". I'll try to expand on that post a bit so the plan is clearer. --Beman
participants (3)
-
Beman Dawes -
David Abrahams -
Doug Gregor