Guidelines to implement Boost library evolution policy (was Boost 2.0)
The Boost Steering Committee set the overall policy for Boost library evolution to C++11, C++14, and beyond at its May 2014 meeting in Aspen. Guidelines to implement that policy are now available at https://svn.boost.org/trac/boost/wiki/BoostEvo The plan is to integrate these guidelines with similar material on the web site in time for the 1.56 release. --The Boost Steering Committee
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Beman Dawes Sent: 06 June 2014 13:03 To: Boost Developers List Subject: [boost] Guidelines to implement Boost library evolution policy (was Boost 2.0)
The Boost Steering Committee set the overall policy for Boost library evolution to C++11, C++14, and beyond at its May 2014 meeting in Aspen.
Guidelines to implement that policy are now available at https://svn.boost.org/trac/boost/wiki/BoostEvo
Good plan :-) Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 01539 561830
Beman Dawes wrote:
The Boost Steering Committee set the overall policy for Boost library evolution to C++11, C++14, and beyond at its May 2014 meeting in Aspen.
Guidelines to implement that policy are now available at https://svn.boost.org/trac/boost/wiki/BoostEvo
Hi there, I find that the case study from Jeff Garland leads to the wrong conclusion. The conclusion in the document is that the case study justifies continuing to support old/ancient compilers. What the case study tells us is that Boost (which version? Let's assume a recent version) helps to migrate from a compiler from the ancient past to a compiler from the very recent past (GCC 4.8). The case study looks to the past. If you want to evolve Boost, then appeal to the use-case of migrating from GCC 4.8 to whatever will be in use 6-10 years from now. That would be looking to the future. Then, thinking mathematically, any migration use-case in the future can be reduced to a previously solved problem plus whatever future Boost does. The Jeff Garland case study tells us that the past problem is already solved using Boost from the present or the past. You don't need to solve that problem again. Solve the present and future problems instead in the evolution of Boost. Put case studies for those in your document instead of the Jeff Garland case study. Thanks, Steve.
On June 7, 2014 4:01:10 PM EDT, Stephen Kelly <hello@steveire.com> wrote:
Beman Dawes wrote:
The Boost Steering Committee set the overall policy for Boost library evolution to C++11, C++14, and beyond at its May 2014 meeting in Aspen.
Guidelines to implement that policy are now available at https://svn.boost.org/trac/boost/wiki/BoostEvo
I find that the case study from Jeff Garland leads to the wrong conclusion. The conclusion in the document is that the case study justifies continuing to support old/ancient compilers.
What the case study tells us is that Boost (which version? Let's assume a recent version) helps to migrate from a compiler from the ancient past to a compiler from the very recent past (GCC 4.8). The case study looks to the past.
Actually, it shows that a Boost that doesn't ignore older compilers and versions of the language provides a bridge to newer compilers and versions of the language.
If you want to evolve Boost, then appeal to the use-case of migrating from GCC 4.8 to whatever will be in use 6-10 years from now. That would be looking to the future. Then, thinking mathematically, any migration use-case in the future can be reduced to a previously solved problem plus whatever future Boost does.
There's nothing in the policy that precludes looking forward. Likewise, there's nothing in the policy that requires support for ancient compilers.
The Jeff Garland case study tells us that the past problem is already solved using Boost from the present or the past. You don't need to solve that problem again.
Who was suggesting that?
Solve the present and future problems instead in the evolution of Boost. Put case studies for those in your document instead of the Jeff Garland case study.
Provide an appropriate case study, with discussion of how it should be incorporated in Boost evolution policy, and we'll consider including it. The point of the one included was too illustrate how a Boost 2.0, which breaks from the past completely, is not the way forward. ___ Rob (Sent from my portable computation engine)
Rob Stewart wrote:
The Jeff Garland case study tells us that the past problem is already solved using Boost from the present or the past. You don't need to solve that problem again.
Who was suggesting that?
The author of the document about the future of Boost currently being discussed.
From the document:
... illustrates why Boost continues to support older compilers and standard libraries
And it then illustrates that 'older' means 1996 era compilers. If you think it should mean something different, I recommend you edit the document, or qualify what 'older' means. Robert Ramey also emailed to make that point in much stronger terms (and on very dubious claims). Robert, if you want to participate in the discussion I recommend you resolve you problem with posting to this mailing list. Thanks, Steve.
On June 8, 2014 5:16:29 AM EDT, Stephen Kelly <hello@steveire.com> wrote:
Rob Stewart wrote:
The Jeff Garland case study tells us that the past problem is already solved using Boost from the present or the past. You don't need to solve that problem again.
Who was suggesting that?
The author of the document about the future of Boost currently being discussed.
From the document:
... illustrates why Boost continues to support older compilers and standard libraries
And it then illustrates that 'older' means 1996 era compilers.
As you said, that problem is already solved. There's nothing that must be done to solve it. The point is that creating a new version of Boost with no support for old platforms does not provide a transition to the brave new world of C++11, 14, and beyond. The policy also permits library authors to break with the past by conditionally adding new features to an existing library, by maintaining two libraries, or by creating entirely new libraries that require new language features. There's nothing in that policy that requires support for any particular old platform. Add always, library authors and maintainers are free to drop support for older platforms add they see fit. ___ Rob (Sent from my portable computation engine)
Rob Stewart wrote:
On June 8, 2014 5:16:29 AM EDT, Stephen Kelly <hello@steveire.com> wrote:
Rob Stewart wrote:
The Jeff Garland case study tells us that the past problem is already solved using Boost from the present or the past. You don't need to solve that problem again.
Who was suggesting that?
The author of the document about the future of Boost currently being discussed.
From the document:
... illustrates why Boost continues to support older compilers and standard libraries
And it then illustrates that 'older' means 1996 era compilers.
As you said, that problem is already solved. There's nothing that must be done to solve it. The point is that creating a new version of Boost with no support for old platforms does not provide a transition to the brave new world of C++11, 14, and beyond.
Migrating to that brave new world requires modularization. Otherwise foo_library can not bump its compiler requirements unless that's ok for all of its dependees. Given the current cyclic dependencies that is a real blocker for everything in the strongly connected graph. So the current work on removing those cycles will prove useful to this discussion. Also, I urge you not to think in terms of language standards. Think in terms of compiler versions and their features. The year of release of a language standard is entirely irrelevant. Consider instead what features are available in the set of minimum compiler requirements you have. It is really no different to the 'can we use member templates' question. http://www.kdab.com/modern-cmake-with-qt-and-boost/#compile-feature-specific... C++ developers probably won't be able to depend on the existence of constexpr in portable code before 2020 (ie, until the MSVC release which supports it is the oldest MSVC version in widespread use). People need to stop thinking about it as a '2011 feature'. However, you can rely on the existence of other features such as decltype and rvalue references whenever MSVC 2010 is the minimum required version (I'm not saying you need to bump it to that now) and other minimum requirements also support the relevant features. So, don't frame questions in your mind as 'can we use C++11?'. Ask instead 'what are our minimum compiler requirements and what features can we rely on from them'. So, what are the current minimum compiler requirements for Boost? Are they sensible? Would a policy which keeps them 'rolling' make sense? Should a support for a compiler *ever* be dropped? Robert Ramey seems to think not. Note that I never suggested a 'big bang' break forward. I suggest only modernizing your toolchain/compiler/stdlib requirements and then making use of the features that become available as a result. It is not clear whether the Boost community wants to do that at all. I get a lot of emails off-list from people who do want that, but they don't write to the list so it's quite useless. Others clearly want no dropping of old compiler/stdlib ever. If you're creating a document about the future of Boost, compiler/stdlib versions is what you need to create a concrete policy about. Instead the document discusses C++11/14 and that's the wrong mindset as I note above. The language standard is incidental. Think about compiler versions and their features.
There's nothing in that policy that requires support for any particular old platform.
Is 'particular' the operative word here?
Add always, library authors and maintainers are free to drop support for older platforms add they see fit.
After modularization, to some extent, yes. Thanks, Steve.
On 6/8/2014 6:46 AM, Stephen Kelly wrote:
Rob Stewart wrote:
On June 8, 2014 5:16:29 AM EDT, Stephen Kelly <hello@steveire.com> wrote:
Rob Stewart wrote:
The Jeff Garland case study tells us that the past problem is already solved using Boost from the present or the past. You don't need to solve that problem again.
Who was suggesting that?
The author of the document about the future of Boost currently being discussed.
From the document:
... illustrates why Boost continues to support older compilers and standard libraries
And it then illustrates that 'older' means 1996 era compilers.
As you said, that problem is already solved. There's nothing that must be done to solve it. The point is that creating a new version of Boost with no support for old platforms does not provide a transition to the brave new world of C++11, 14, and beyond.
Migrating to that brave new world requires modularization. Otherwise foo_library can not bump its compiler requirements unless that's ok for all of its dependees.
Given the current cyclic dependencies that is a real blocker for everything in the strongly connected graph. So the current work on removing those cycles will prove useful to this discussion.
Also, I urge you not to think in terms of language standards. Think in terms of compiler versions and their features.
Realistically this requires a knowledge of particular compilers and their versions that it is nearly impossible for any particular developer to have. Am I really expected to use or not use a C++ language feature in a particular release of my theoretical library because Compiler X, version Y does or does not support some C++11/C++14 feature ? I do not believe such thinking is conducive to expert programming. OTOH I agree with you that it is realistic for some version of a library to say that older and/or non-compliant compilers/versions which do not support C++ feature X are not usable with version Y of a library. So that if the end-user is still using that compiler/version they must use some earlier version of the library ( or not use the library at all if it is a new library using some advanced C++ feature to accomplish what it needs ).
On Sun, Jun 8, 2014 at 9:51 AM, Edward Diener <eldiener@tropicsoft.com> wrote:
Rob Stewart wrote:
Also, I urge you not to think in terms of language standards. Think in terms of compiler versions and their features.
Realistically this requires a knowledge of particular compilers and their versions that it is nearly impossible for any particular developer to have. Am I really expected to use or not use a C++ language feature in a particular release of my theoretical library because Compiler X, version Y does or does not support some C++11/C++14 feature ? I do not believe such thinking is conducive to expert programming.
A developer does not have to track compiler/library releases. Boost.Config macros take care of tracking, backed up by the regression testers. Also Compilers are starting to support the C++ committee's Standing Document 6. See http://isocpp.org/std/standing-documents/sd-6-sg10-feature-test-recommendati... and that should help Boost.config track who is supporting what. --Beman
On 6/8/2014 11:54 AM, Beman Dawes wrote:
On Sun, Jun 8, 2014 at 9:51 AM, Edward Diener <eldiener@tropicsoft.com> wrote:
Rob Stewart wrote:
Also, I urge you not to think in terms of language standards. Think in terms of compiler versions and their features.
Realistically this requires a knowledge of particular compilers and their versions that it is nearly impossible for any particular developer to have. Am I really expected to use or not use a C++ language feature in a particular release of my theoretical library because Compiler X, version Y does or does not support some C++11/C++14 feature ? I do not believe such thinking is conducive to expert programming.
A developer does not have to track compiler/library releases. Boost.Config macros take care of tracking, backed up by the regression testers.
I agree this is the best way to work with Boost and the C++ language standard. But when I do this I am not thinking "in terms of compiler versions and their features" as Stephen Kelly suggests but only in terms of C++ features as they are supported by Boost in Config.
On Sun, Jun 8, 2014 at 5:45 PM, Edward Diener <eldiener@tropicsoft.com> wrote:
On 6/8/2014 11:54 AM, Beman Dawes wrote:
On Sun, Jun 8, 2014 at 9:51 AM, Edward Diener <eldiener@tropicsoft.com> wrote:
Rob Stewart wrote:
Also, I urge you not to think in terms of language standards. Think in terms of compiler versions and their features.
Realistically this requires a knowledge of particular compilers and their versions that it is nearly impossible for any particular developer to have. Am I really expected to use or not use a C++ language feature in a particular release of my theoretical library because Compiler X, version Y does or does not support some C++11/C++14 feature ? I do not believe such thinking is conducive to expert programming.
A developer does not have to track compiler/library releases. Boost.Config macros take care of tracking, backed up by the regression testers.
I agree this is the best way to work with Boost and the C++ language standard. But when I do this I am not thinking "in terms of compiler versions and their features" as Stephen Kelly suggests but only in terms of C++ features as they are supported by Boost in Config.
Good point. --Beman
On 8 Jun 2014 at 11:16, Stephen Kelly wrote:
The Jeff Garland case study tells us that the past problem is already solved using Boost from the present or the past. You don't need to solve that problem again. [snip] And it then illustrates that 'older' means 1996 era compilers.
If you think it should mean something different, I recommend you edit the document, or qualify what 'older' means.
No, I think Jeff's use case does refer to that age of compiler. To my best understanding, he had a large code base based on ancient compilers which he successfully got compiling with C++ 11 mode switched on thanks to Boost. I understand he believes that a more rapid switch of Boost to requiring all C++ 11 would be a great loss to Boost and to those in his situation. I understand he therefore believes such ideas should be opposed. I agree that this is a valuable use case for Boost, and one worth significant monies to large corporate persons as well as to Jeff. The bee in my bonnet is why bug fixing and maintaining C++ 98 compatibility is expected for free from volunteers. I think that if they want C++ 98 support, those users should pay what such support is worth. Meanwhile, the volunteers can get back to pushing the state of the art as it is their family time, not free work donated to wealthy corporate persons who give little to nothing back in return.
Robert Ramey also emailed to make that point in much stronger terms (and on very dubious claims).
Robert, if you want to participate in the discussion I recommend you resolve you problem with posting to this mailing list.
I do wish Robert would email this list instead of privately, unless what he speaks about isn't for public consumption. I already know Robert's position, though don't get me wrong I don't mind being reminded in case my memory is faulty. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
Niall Douglas wrote:
On 8 Jun 2014 at 11:16, Stephen Kelly wrote:
The Jeff Garland case study tells us that the past problem is already solved using Boost from the present or the past. You don't need to solve that problem again. [snip] And it then illustrates that 'older' means 1996 era compilers.
If you think it should mean something different, I recommend you edit the document, or qualify what 'older' means.
No, I think Jeff's use case does refer to that age of compiler. To my best understanding, he had a large code base based on ancient compilers which he successfully got compiling with C++ 11 mode switched on thanks to Boost. I understand he believes that a more rapid switch of Boost to requiring all C++ 11 would be a great loss to Boost and to those in his situation. I understand he therefore believes such ideas should be opposed.
It looks like the document about the future of Boost is making it a policy that no compiler support should be dropped ever and that ancients are supported by policy. That definitely affects the code, and is an idea disconnected from reality - some ancients were dropped globally already months ago and that has enabled some of the modularization work ('What is this abstraction? Oh, it's obsolete. We can remove an edge.'). Modularization is taking advantage of that, and when the code is more modular, I'm sure people will want to bump compiler requirements. As I've said many times though, you don't even have to say 'c++11' in this discussion - bumping compiler requirements would allow the use of partial specialization in Boost (a feature of ancient compiler versions). What would your paragraph look like if you removed all reference to 'c++11' and had that in mind? Is the position of the document a reasonable position to hold? It is not clear to me how updating the requirements of Boost master branch could possibly be a great loss to his situation. That does not make older Boost releases disappear. However, the document forwards the idea that it would indeed be a great loss and must not be done.
I do wish Robert would email this list instead of privately
He emailed the list and CC'd me as it was a reply to my mail. His mail did not reach the mailing list. That's what I'm suggesting he resolve. Thanks, Steve.
On Mon, Jun 9, 2014 at 12:58 AM, Stephen Kelly <hello@steveire.com> wrote:
Niall Douglas wrote:
On 8 Jun 2014 at 11:16, Stephen Kelly wrote:
The Jeff Garland case study tells us that the past problem is already solved using Boost from the present or the past. You don't need to solve that problem again. [snip] And it then illustrates that 'older' means 1996 era compilers.
If you think it should mean something different, I recommend you edit the document, or qualify what 'older' means.
No, I think Jeff's use case does refer to that age of compiler. To my best understanding, he had a large code base based on ancient compilers which he successfully got compiling with C++ 11 mode switched on thanks to Boost. I understand he believes that a more rapid switch of Boost to requiring all C++ 11 would be a great loss to Boost and to those in his situation. I understand he therefore believes such ideas should be opposed.
It looks like the document about the future of Boost is making it a policy that no compiler support should be dropped ever and that ancients are supported by policy.
To try to reduce the chance of a reader jumping to that conclusion, I've changed the case study introduction from: This case study from Jeff Garland illustrates why Boost continues to support older compilers and standard libraries. to: This case study from Jeff Garland illustrates why many Boost libraries leave old compiler and standard library workarounds in place as long as they don't impede library evolution: Thanks, --Beman
participants (6)
-
Beman Dawes -
Edward Diener -
Niall Douglas -
Paul A. Bristow -
Rob Stewart -
Stephen Kelly