On 10/14/2017 12:39 PM, James E. King, III via Boost wrote:
On Sat, Oct 14, 2017 at 12:33 PM, Robert Ramey via Boost < boost@lists.boost.org> wrote:
On 10/14/17 8:37 AM, Vinnie Falco via Boost wrote:
On Sat, Oct 14, 2017 at 8:33 AM, Robert Ramey via Boost
Not completely related but I have observed that while Boost has
amazing facilities for introducing new libraries (the formal review process)
there is nothing for gracefully retiring old libraries. Or
I have a solution to this - as described part of my boost 2.0 talk. But the world isn't ready for me to start flogging it yet.
for that matter old toolchains.
My point is that selection of toolchains to support and test is upto the library maintainer. There is not communal agreement necessary.
That would be far too confusing to consumers of the boost library set. Each release of the boost library set should have a standard set of compilers that are tested. If maintainers of each library want to support more compilers, that is acceptable and should be documented in the library docs. If maintainers of each library want to support less compilers, that would not be acceptable.
I disagree with this simply because it is very possible that a given Boost library will not work at all with a given compiler/version simply because of the deficiencies of that compiler when used by that library. Ideally, yes, Boost as a whole should try to support certain modern compilers/versions across the board. But in practice, for some 130+ libraries this is not tenable.
In terms of potentially dropping msvc-7.1, my original suggestion was for the next whole release cycle.
- Jim