[boost] A possible date for dropping c++03 support

Subject: [boost] A possible date for dropping c++03 support
From: Mike Dev (mike.dev_at_[hidden])
Date: 2018-08-30 17:21:20

> -----Original Message-----
> From: Boost <boost-bounces_at_[hidden]> On Behalf Of Edward Diener via Boost
> Sent: Thursday, August 30, 2018 10:54 PM
> 
> On 8/30/2018 8:02 AM, Mike Dev via Boost wrote:
> >> -----Original Message-----
> >> From: Boost <boost-bounces_at_[hidden]> On Behalf Of Alexander Grund via Boost
> >> Sent: Wednesday, August 29, 2018 3:12 PM
> >>
> 
> The "pushing on" probably needs someone from the Boost steering
> committee involved.
>
Sounds right. I admit I've no idea about things like this work in boost

> >>
> >> [1] We only consider the following compilers/toolchains to have sufficient
> >>      c++11 support to be supported:
> >>      - MSVC 2015 and up,
> >>      - gcc 4.9 and up,
> >>      - clang3.3 and up (when paired with an appropriate standard library
> >>        implementation)
> >>      - [ICC? CUDA? Any other?]
> 
> I would emphasize what toolchains are actually tested rather than
> supported toolchains. In general developers/maintainers care much less
> about toolchains than they do about C++ compiler levels and features in
> their library. If we say that we do not support Intel or Oracle
> compilers, for example, we are denigrating toolchains that may well work
> fine with most Boost libraries. If we explain which toolchains we
> regularly test, this then is an impetus for certain toolchains which we
> do not regularly test to offer ways/means to have those toolchains
> tested against Boost libraries. The more toolchains we can successfully
> test against Boost libraries the more end-users we have.

Agreed 

> 
> It is very difficult, if not impossible, for a library to know what
> toolchains are supported by that library. I agree that language level
> should be either in the documentation directly and/or in the meta
> information for each library, preferably both if the meta information
> can enable the Boost web pages to list the language level and/or
> language features used for each library.

Well, with the projects I was involved we didn't support what we didn't 
test ( or rather we decided what we wanted to support and tested the heck 
out of it) but sure, use whatever term you think is more appropriate in this 
context.

> >
> > - If this goes through, could someone create a c++11 branch (or similar)
> >    in the github main project, where libraries that want to start early
> >    can make their expected changes easily visible to others?
> 
> I think a c++11 branch as you have described brings an unneeded
> complication. Any library which currently supports c++03 and wants to
> use c++11 features will just do so. Since we wouldn't officially be
> testing at the c++03 level there is nothing further to do in
> transitioning, and each library developer/maintainer can continue to do
> his own local testing as he wants anyway.

Just to make sure there isn't a misunderstanding: the c++11 branch would 
be for the time frame from now until boost 2020 where those changes could
the be merged to develop and then master.
 
Maybe c++11 is a bad branch name. In normal sem-ver terms it would be the creation
of a branch for the next major version while there are still 1-2 more minor
version upgdates in the making. But you are probably right and anyway it can
 wait.

> 
> Thanks ! I think your text is generally excellent.

Thanks