[1.47.0] Release branch now closed
The release branch is now close, i.e. the release is frozen, for further changes. This means that commits to the release branch will fail without explicit authorization. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail
Rene, I would like to update the Spirit docs one last time before the release. Would that be possible? Regards Hartmut --------------- http://boost-spirit.com
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Rene Rivera Sent: Monday, June 13, 2011 10:27 AM To: boost@lists.boost.org Subject: [boost] [1.47.0] Release branch now closed
The release branch is now close, i.e. the release is frozen, for further changes. This means that commits to the release branch will fail without explicit authorization.
-- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 6/13/2011 12:36 PM, Hartmut Kaiser wrote:
I would like to update the Spirit docs one last time before the release. Would that be possible?
We usually allow documentation changes almost to the last minute.. So yes. Obviously the sooner you make that update the smoother the beta next Monday will go. When you do the commit add "authorized by rene" to the commit message. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail
On 6/13/2011 12:36 PM, Hartmut Kaiser wrote:
I would like to update the Spirit docs one last time before the release. Would that be possible?
We usually allow documentation changes almost to the last minute.. So yes. Obviously the sooner you make that update the smoother the beta next Monday will go. When you do the commit add "authorized by rene" to the commit message.
Thanks Rene. I just realized there are other merges pending, which are related to renaming an example and to fixing a couple of minor bugs in several of the Spirit examples. The change sets are rev. 72465, 72467, 72479, and 72561 (see diffs attached). All changes are trivial and no Boost libraries are affected. Ok to commit those as well? Regards Hartmut --------------- http://boost-spirit.com
On 6/13/2011 2:33 PM, Hartmut Kaiser wrote:
On 6/13/2011 12:36 PM, Hartmut Kaiser wrote:
I would like to update the Spirit docs one last time before the release. Would that be possible?
We usually allow documentation changes almost to the last minute.. So yes. Obviously the sooner you make that update the smoother the beta next Monday will go. When you do the commit add "authorized by rene" to the commit message.
Thanks Rene.
I just realized there are other merges pending, which are related to renaming an example and to fixing a couple of minor bugs in several of the Spirit examples. The change sets are rev. 72465, 72467, 72479, and 72561 (see diffs attached).
All changes are trivial and no Boost libraries are affected. Ok to commit those as well?
Yes. Next time please just include links to the trac changeset. As it's a bit less effort to just look at them there. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail
On 6/13/2011 2:33 PM, Hartmut Kaiser wrote:
On 6/13/2011 12:36 PM, Hartmut Kaiser wrote:
I would like to update the Spirit docs one last time before the release. Would that be possible?
We usually allow documentation changes almost to the last minute.. So yes. Obviously the sooner you make that update the smoother the beta next Monday will go. When you do the commit add "authorized by rene" to the commit message.
Thanks Rene.
I just realized there are other merges pending, which are related to renaming an example and to fixing a couple of minor bugs in several of the Spirit examples. The change sets are rev. 72465, 72467, 72479, and 72561 (see diffs attached).
All changes are trivial and no Boost libraries are affected. Ok to commit those as well?
Yes. Next time please just include links to the trac changeset. As it's a bit less effort to just look at them there.
Committed. Thanks! Regards Hartmut --------------- http://boost-spirit.com
Rene, there is a small change in boost/exception/exception.hpp that has been sitting in Trunk for weeks now, I'd like to merge it to release. It just adds GCC visibility to the boost::exception type, and this is the patch: https://svn.boost.org/trac/boost/attachment/ticket/4594/exception.patch I'm ready to commit it if the release team allows it. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode On Mon, Jun 13, 2011 at 8:26 AM, Rene Rivera <grafikrobot@gmail.com> wrote:
The release branch is now close, i.e. the release is frozen, for further changes. This means that commits to the release branch will fail without explicit authorization.
-- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 6/14/2011 1:41 PM, Emil Dotchevski wrote:
Rene, there is a small change in boost/exception/exception.hpp that has been sitting in Trunk for weeks now, I'd like to merge it to release. It just adds GCC visibility to the boost::exception type, and this is the patch:
https://svn.boost.org/trac/boost/attachment/ticket/4594/exception.patch
I'm ready to commit it if the release team allows it.
Where's the trac link to the change set? Is there a test for this? Is the test in the release branch also? What platforms does this impact? What other libraries does this impact? Are other libraries failing because of not having this change? Sorry for all the questions, but we need to asses the risk. Especially for something that doesn't seem critical and should have been merge to release long ago ;-) -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail
On Tue, Jun 14, 2011 at 12:06 PM, Rene Rivera <grafikrobot@gmail.com> wrote:
On 6/14/2011 1:41 PM, Emil Dotchevski wrote:
Rene, there is a small change in boost/exception/exception.hpp that has been sitting in Trunk for weeks now, I'd like to merge it to release. It just adds GCC visibility to the boost::exception type, and this is the patch:
https://svn.boost.org/trac/boost/attachment/ticket/4594/exception.patch
I'm ready to commit it if the release team allows it.
Where's the trac link to the change set? Is there a test for this? Is the test in the release branch also? What platforms does this impact? What other libraries does this impact? Are other libraries failing because of not having this change?
Sorry for all the questions, but we need to asses the risk.
No, I hear you, this might be considered too risky at this point. The change affects GCC only, it makes class boost::exception visible across shared library boundaries. The header file in question contains a declaration of boost::exception and a definition of boost::exception. The definition is already tagged with GCC visibility (including in the release branch). This change applies the same settings to the declaration. Other libraries do not fail because of not having this change. As long as it compiles, the change should not affect other libraries. It has been sitting in Trunk for quite some time and hasn't broken anything AFAIK. Emil
On 6/14/2011 4:24 PM, Emil Dotchevski wrote:
On Tue, Jun 14, 2011 at 12:06 PM, Rene Rivera<grafikrobot@gmail.com> wrote:
On 6/14/2011 1:41 PM, Emil Dotchevski wrote:
Rene, there is a small change in boost/exception/exception.hpp that has been sitting in Trunk for weeks now, I'd like to merge it to release. It just adds GCC visibility to the boost::exception type, and this is the patch:
https://svn.boost.org/trac/boost/attachment/ticket/4594/exception.patch
I'm ready to commit it if the release team allows it.
Where's the trac link to the change set? Is there a test for this? Is the test in the release branch also? What platforms does this impact? What other libraries does this impact? Are other libraries failing because of not having this change?
Sorry for all the questions, but we need to asses the risk.
No, I hear you, this might be considered too risky at this point.
From reading the original ticket for this <https://svn.boost.org/trac/boost/ticket/4594>.. It doesn't sound like the issue is fully resolved. Also looking at the current state, and logs, of boost/exception/* it looks like there's a considerable number of other changes after the above. Which doesn't lead me to believe this is actually tested enough in isolation to just merge, instead of merging the whole of the exception changes. So, sorry, no. It would be better/safer to wait for early in the next release cycle and merge all the exception library changes to release. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail
El 13/06/2011 17:26, Rene Rivera escribió:
The release branch is now close, i.e. the release is frozen, for further changes. This means that commits to the release branch will fail without explicit authorization.
Sigh! I've been on holidays for 15 days and I see a new schedule was set in May 28 and now I see the release branch is frozen. This is not a request to delay anything, as I know I should have merged things to release much earlier. The question is: Any plan to release Boost 1.48 soon? I don't want to repeat my mistake as have Boost.Move plus some Interprocess/Intrusive changes waiting to be merged to release. Best, Ion
El 13/06/2011 17:26, Rene Rivera escribió:
The release branch is now close, i.e. the release is frozen, for further changes. This means that commits to the release branch will fail without explicit authorization.
Sigh!
I've been on holidays for 15 days and I see a new schedule was set in May 28 and now I see the release branch is frozen.
This is not a request to delay anything, as I know I should have merged things to release much earlier.
The question is: Any plan to release Boost 1.48 soon? I don't want to repeat my mistake as have Boost.Move plus some Interprocess/Intrusive changes waiting to be merged to release.
Does this mean Boost.Move will not be part of V1.47? That would be a shame! We're waiting for this for too long already. Release managers: Please allow merging it even if the branch is frozen. Adding this library will not break anything else. The merge seems to be low risk, even more as it's sitting in trunk for quite some time now. Regards Hartmut --------------- http://boost-spirit.com
El 15/06/2011 10:29, Hartmut Kaiser escribió:
Release managers: Please allow merging it even if the branch is frozen. Adding this library will not break anything else. The merge seems to be low risk, even more as it's sitting in trunk for quite some time now.
The issue is that merging Move would require also updating Intrusive/Interprocess to the official move library. I think we can ambiguity issues between code using the old Interprocess/Intrusive and Move. Changes in Interprocess/Intrusive libraries, are mainly find-replace changes in namespaces (previously was in ::boost::interprocess::detail) and macros. I don't think waiting for boost 1.48 is a big problem if it's version is scheduled soon. No 1.47 library depends on Move. I think it's important to maintain merging rules against late mergers ;-) If 1.48 is going to take a long time and users badly need the library I would propose a merge, wait a couple of cycles (tests seem fine in trunk), and then decide. Best, Ion
On Wed, Jun 15, 2011 at 11:43:59AM +0200, Ion Gaztañaga wrote:
El 15/06/2011 10:29, Hartmut Kaiser escribió:
Release managers: Please allow merging it even if the branch is frozen. Adding this library will not break anything else. The merge seems to be low risk, even more as it's sitting in trunk for quite some time now.
The issue is that merging Move would require also updating Intrusive/Interprocess to the official move library. I think we can ambiguity issues between code using the old Interprocess/Intrusive and Move. Changes in Interprocess/Intrusive libraries, are mainly find-replace changes in namespaces (previously was in ::boost::interprocess::detail) and macros.
I don't think waiting for boost 1.48 is a big problem if it's version is scheduled soon. No 1.47 library depends on Move. I think it's important to maintain merging rules against late mergers ;-)
If 1.48 is going to take a long time and users badly need the library I would propose a merge, wait a couple of cycles (tests seem fine in trunk), and then decide.
What is the policy on when and how to release point releases (1.47.1?). Are they just for bugfixes or can you slip in new libraries as well in one? -- Lars Viklund | zao@acc.umu.se
On 15 June 2011 11:16, Lars Viklund <zao@acc.umu.se> wrote:
What is the policy on when and how to release point releases (1.47.1?). Are they just for bugfixes or can you slip in new libraries as well in one?
They're for bugfixes only. And we want to have new libraries ready early in the release process so there's plenty of time for potential problems to be found.
On 6/15/2011 5:40 PM, Daniel James wrote:
On 15 June 2011 11:16, Lars Viklund <zao@acc.umu.se> wrote:
What is the policy on when and how to release point releases (1.47.1?). Are they just for bugfixes or can you slip in new libraries as well in one?
They're for bugfixes only.
And we want to have new libraries ready early in the release process so there's plenty of time for potential problems to be found.
Daniel is right. It's far too late to add a new library to 1.47. Boost 1.48 should come out on schedule 3 months later, hopefully with Boost.Move. -- Eric Niebler BoostPro Computing http://www.boostpro.com
El 15/06/2011 19:50, Eric Niebler escribió:
On 6/15/2011 5:40 PM, Daniel James wrote:
On 15 June 2011 11:16, Lars Viklund<zao@acc.umu.se> wrote: Daniel is right. It's far too late to add a new library to 1.47. Boost 1.48 should come out on schedule 3 months later, hopefully with Boost.Move.
I agree Eric. I think 3 months is ok, I just wanted to confirm Boost 1.48 is planned shortly after 1.47. Best, Ion
2011/6/15 Ion Gaztañaga <igaztanaga@gmail.com>:
El 15/06/2011 19:50, Eric Niebler escribió:
On 6/15/2011 5:40 PM, Daniel James wrote:
On 15 June 2011 11:16, Lars Viklund<zao@acc.umu.se> wrote:
Daniel is right. It's far too late to add a new library to 1.47. Boost 1.48 should come out on schedule 3 months later, hopefully with Boost.Move.
I agree Eric. I think 3 months is ok, I just wanted to confirm Boost 1.48 is planned shortly after 1.47.
While the release managers haven't talked about the 1.48.0 schedule yet, I personally would like to get back to our traditional quarterly schedule. That would mean 1.48.0 would be scheduled for the first Monday in August. --Beman
On 16 June 2011 16:14, Beman Dawes <bdawes@acm.org> wrote:
While the release managers haven't talked about the 1.48.0 schedule yet, I personally would like to get back to our traditional quarterly schedule. That would mean 1.48.0 would be scheduled for the first Monday in August.
We haven't got enough time for that. If we release 1.47 after a 2 week beta (i.e. pretty quickly), it will be released on 4th July, leaving just under a month before the first Monday in August.
On Thu, Jun 16, 2011 at 5:28 PM, Daniel James <dnljms@gmail.com> wrote:
On 16 June 2011 16:14, Beman Dawes <bdawes@acm.org> wrote:
While the release managers haven't talked about the 1.48.0 schedule yet, I personally would like to get back to our traditional quarterly schedule. That would mean 1.48.0 would be scheduled for the first Monday in August.
We haven't got enough time for that. If we release 1.47 after a 2 week beta (i.e. pretty quickly), it will be released on 4th July, leaving just under a month before the first Monday in August.
In that case returning to the quaterly schedule would mean 1.48 in November. Olaf
On Thu, Jun 16, 2011 at 11:28 AM, Daniel James <dnljms@gmail.com> wrote:
On 16 June 2011 16:14, Beman Dawes <bdawes@acm.org> wrote:
While the release managers haven't talked about the 1.48.0 schedule yet, I personally would like to get back to our traditional quarterly schedule. That would mean 1.48.0 would be scheduled for the first Monday in August.
We haven't got enough time for that. If we release 1.47 after a 2 week beta (i.e. pretty quickly), it will be released on 4th July, leaving just under a month before the first Monday in August.
Agreed, but we could aim for as short a 1.48 schedule as is reasonable so that the 1.49 schedule is then back on the quarterly cycle. This really needs to be discussed in a separate thread, which I'll start right away. So please reply to it rather than this message. Thanks, --Beman
Hi Rene, On 13-6-2011 17:26, Rene Rivera wrote:
The release branch is now close, i.e. the release is frozen, for further changes. This means that commits to the release branch will fail without explicit authorization.
I got this message on Boost.Geometry this morning on the ggl-mailing list:
In mingw32 g++ 4.5.2 with NDEBUG defined I've received errors:
boost/geometry/algorithms/detail/overlay/handle_tangencies.hpp:309:13: error: 'cout' is not a member of 'std'
boost/geometry/algorithms/detail/overlay/handle_tangencies.hpp:364:9: error: 'cout' is not a member of 'std'
There are #ifdefs BOOST_GEOMETRY_DEBUG_ENRICH commented out.
Was my fault and I just fixed it. Is it still possible to merge this minor fix into the release branch? It is only one file, contains no side-effects, no libraries are dependant on this new library. If not merged, it will give compiler errors to users not including <iostream> (and theoretically might give spurious output but that is not expected). If permitted I will do the merge tonight or tomorrow. Thanks, Barend
On 15 June 2011 17:21, Barend Gehrels <barend@xs4all.nl> wrote:
Was my fault and I just fixed it. Is it still possible to merge this minor fix into the release branch? It is only one file, contains no side-effects, no libraries are dependant on this new library. If not merged, it will give compiler errors to users not including <iostream> (and theoretically might give spurious output but that is not expected).
If permitted I will do the merge tonight or tomorrow.
I assume you mean: https://svn.boost.org/trac/boost/changeset/72603/ If so, then yes. If you can, you should give it a day or two to see the regression test results. I think you'll need to include something like, "Authorized by Daniel James" in your commit for it to work.
Hi Daniel, On 15-6-2011 19:36, Daniel James wrote:
On 15 June 2011 17:21, Barend Gehrels<barend@xs4all.nl> wrote:
Was my fault and I just fixed it. Is it still possible to merge this minor fix into the release branch? It is only one file, contains no side-effects, no libraries are dependant on this new library. If not merged, it will give compiler errors to users not including<iostream> (and theoretically might give spurious output but that is not expected).
If permitted I will do the merge tonight or tomorrow. I assume you mean:
https://svn.boost.org/trac/boost/changeset/72603/
If so, then yes. If you can, you should give it a day or two to see the regression test results. I think you'll need to include something like, "Authorized by Daniel James" in your commit for it to work.
OK, yes that was the change; will act accordingly. Thanks, Barend
Hi Daniel, On 15-6-2011 19:36, Daniel James wrote:
If permitted I will do the merge tonight or tomorrow. I assume you mean:
https://svn.boost.org/trac/boost/changeset/72603/
If so, then yes. If you can, you should give it a day or two to see the regression test results. I think you'll need to include something like, "Authorized by Daniel James" in your commit for it to work.
OK, the regression tests all still look as previously. So I committed including your authorization hint. Thanks, Barend
On 17 June 2011 19:48, Barend Gehrels <barend@xs4all.nl> wrote:
OK, the regression tests all still look as previously. So I committed including your authorization hint.
Thanks for humouring me. I noticed that in your documentation you use '__boost__' which I assume is meant to be a macro, but it isn't defined (you should be able to merge documentation fixes without an authorisation message).
Hi Daniel, On 17-6-2011 20:58, Daniel James wrote:
I noticed that in your documentation you use '__boost__' which I assume is meant to be a macro, but it isn't defined (you should be able to merge documentation fixes without an authorisation message).
Thanks! Fixed in trunk and tried to merge, but I get the message: Commit failed (details follow): Commit blocked by pre-commit hook (exit code 1) with output: UU branches/release/libs/geometry/doc/geometry.qbk Is that because the branch is closed now? Regards, Barend
On 17 June 2011 22:54, Barend Gehrels <barend@xs4all.nl> wrote:
Fixed in trunk and tried to merge, but I get the message:
Commit failed (details follow): Commit blocked by pre-commit hook (exit code 1) with output: UU branches/release/libs/geometry/doc/geometry.qbk
Is that because the branch is closed now?
Sorry, put "Authorized by Daniel James" in again, and it should work. It's meant to be set up to allow documentation changes without that, but I guess it isn't working (or perhaps hasn't been done yet).
Hi Daniel, On 18-6-2011 0:02, Daniel James wrote:
On 17 June 2011 22:54, Barend Gehrels<barend@xs4all.nl> wrote:
Fixed in trunk and tried to merge, but I get the message:
Commit failed (details follow): Commit blocked by pre-commit hook (exit code 1) with output: UU branches/release/libs/geometry/doc/geometry.qbk
Is that because the branch is closed now? Sorry, put "Authorized by Daniel James" in again, and it should work. It's meant to be set up to allow documentation changes without that, but I guess it isn't working (or perhaps hasn't been done yet).
Yes, it works! Thanks again, Barend
On 1:59 PM, Rene Rivera wrote:
The release branch is now close, i.e. the release is frozen, for further changes. This means that commits to the release branch will fail without explicit authorization.
The Boost.Thread patch for Mingw-64 is crucial for that important platform. <https://svn.boost.org/trac/boost/ticket/4849> It has been patched into the trunk for three months without complaint, and just needs to be shepherded to the release branch. Could you please do this? Thanks in Advance, -Jim <http://lists.boost.org/Archives/boost/2011/06/182599.php>
Can I merge this change to iostreams? https://svn.boost.org/trac/boost/changeset/72543 It cleans up an exception safety issue. In the case of 'close' throwing an exception, 'reset' needs to be called in order to delete the allocated resources. The test results are looking okay. There are a few failures but these seem to be caused either by dependencies or because bzip is missing or hasn't linked correctly, rather than a problem with this change. thanks, Daniel
On 6/18/2011 4:50 AM, Daniel James wrote:
Can I merge this change to iostreams?
https://svn.boost.org/trac/boost/changeset/72543
It cleans up an exception safety issue. In the case of 'close' throwing an exception, 'reset' needs to be called in order to delete the allocated resources.
The test results are looking okay. There are a few failures but these seem to be caused either by dependencies or because bzip is missing or hasn't linked correctly, rather than a problem with this change.
Looks safe enough.. And reset looks idempotent, so should be OK to execute even if the close fails. So, yes go ahead. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail
On 6/18/2011 8:56 AM, Rene Rivera wrote:
On 6/18/2011 4:50 AM, Daniel James wrote:
Can I merge this change to iostreams?
It looks like the merge to release included way more than just that changeset. Please fix ASAP. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail
On 6/18/2011 10:13 AM, Daniel James wrote:
On 18 June 2011 16:05, Rene Rivera<grafikrobot@gmail.com> wrote:
It looks like the merge to release included way more than just that changeset. Please fix ASAP.
That's just merge tracking data.
I see. Up to now I had only see those on directories. So I was mislead :-\ -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail
participants (12)
-
Barend Gehrels -
Beman Dawes -
Daniel James -
Emil Dotchevski -
Emil Dotchevski -
Eric Niebler -
Hartmut Kaiser -
Ion Gaztañaga -
Jim Bell -
Lars Viklund -
Olaf van der Spek -
Rene Rivera