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

Subject: Re: [boost] A possible date for dropping c++03 support
From: Bjørn Roald (bjorn.roald_at_[hidden])
Date: 2018-08-30 21:59:05

> On 30 Aug 2018, at 19:39, Mateusz Loskot via Boost <boost_at_[hidden]> wrote:
> 
> On Thu, 30 Aug 2018, 19:27 Glen Fernandes via Boost, <boost_at_[hidden]>
> wrote:
> 
>> On Thursday, August 30, 2018, Andrey Semashev wrote:
>> 
>>> On 08/30/18 20:05, Peter Dimov wrote:
>>> 
>>>>>> - The default language level for b2 builds will be at least c++11
>>>>> 
>>>> 
>>>> That's going to be a bit complicated as we don't know in general what
>> the
>>>> default should be, but in any case C++11 is very rarely it. In fact
>> using
>>>> C++14 unconditionally will probably be better than trying to be clever.
>>>> 
>>> 
>>> +1. If we're going to drop C++03, we might as well require C++14 as the
>>> baseline.
>>> 
>>> 
>> +1. It also makes for a better sounding announcement.
>> 
> 
> 
> +1. Yes, please.
> 

It seems to be a problem that this is a moving target.  Why not C++17, and hopefully in 2 or 3 years maybe C++20?  A reasonable strategy to deal with this being a moving target is needed.  Shall such baseline changes as time passes be expected by everybody, or is this a one-off thing? 
 
If we expect this to re-occur to Boost every so often, why not establish a work-flow for dealing with this that can off-load burden on maintainers while providing some defined service level for users falling behind as they are tied to old tools or language versions.  Below are some wild ideas to that end.  It is likely these may at first seem too radical, but I am not too sure they are. May any of this be a reasonable approach to handling the moving language target for Boost?

Introduce a new «Boost Language Version Support Policy» :
Boost will move to a new language version as soon as several major compilers and their std libraries on the major desktop platforms support it in a reasonably complete manner.  

It is to be determined what these words means as far as exactly how to determine when it is time to move and what moving means.  The major idea is to ensure and make it clear that the master branch and thus future of Boost is primarily:

- A breeding ground for new ideas and libraries that may be candidates for C++ standardization.
- A place for other libraries complementing the latest C++ standard that is useful for the C++ community.

The idea is that Boost is best serving C++ future if support for older language version is not holding it back.  Other than that there is no need to change any code to move Boost forward to the next language version, but doing so allow maintainers to rethink their designs in terms of new standard language and library features.  It is also reasonable to stop testing for the older language versions. It may make sense to test for support of older language versions on a library by library level for some time after a move, if so this should be up to the individual maintainer.

Every time a language version is left behind, a branch for long term support is created based on the last boost version supporting some old language standard.  A branch name of the form boost_1_68_LTS shall be used for this.  The intention is to leave these branches unchanged unless critical bug fixes are needed — no feature creep or back porting of new features from the future shall ever go into LTS branches.  Such creatures may live in forks, see below.  LTS branches is updated with fixes from hot fix branches in git-flow manner, or in some other defined work flow.  This should allow users to pick specific fixes or simply all the latest in the LTS.  Whether the boost release team shall or will release new minor Boost releases based on submodule commits in the LTS branch shall be entirely up to them, this may not be needed as it should always be possible to check out the LTS branch in some simple and defined way, build this boost snapshot, and expect it to work at least as good as the original boost baseline release.  Achieving this will likely require some procedures, strict discipline and some enforcement to succeed.  Hence defining a role as gate-keeper allowing each hot fix into the LTS branch may be a good idea or even essential. 

If institutions or individuals need other fixes or enhancements to the LTS branch, they can make the fixes themselves. Hopefully they can contribute to the community in their own forks of boost repositories at GitHub.  If people behind these forks organize their  work in some way, not to be governed by Boost, such support for old boost versions may be a substantial and a good contribution to a wider sub-set of the boost user community. Not only to those involved in the fork maintenance which likely are users in need as well.  Back porting new boost features to LTS branch shall end up in forks, not in LTS branches.  This rule apply even if the boost library maintainer is involved.  Groups working on forks may provide their own releases of parts or all of Boost libraries outside Boost.org governance. Users of those forked libraries must trust their maintainers, and not the boost maintainers.  

It is important that the support burden (as in expectation of support) for old boost versions is out of the hands of the original maintainers. Some maintainers may be strongly determined to keep supporting support old compilers in some way or capacity.  That is fine but SHALL NOT be expected.  I would hope most maintainers let the old go to the point it make sense for them by being ensured there is a system to support users that are left behind with old C++ language support, or at least to allow them to help themselves.  There will likely be variations in priorities between maintainers here, and that is fine, but maintainers shall not expect their dependencies to other libraries in boost, on the master branch, to keep supporting old language versions or their legacy APIs soely to make support of LTS branches simpler.  

Some library maintainers might retire their library at an LTS version, and not move forward. This may be a good thing as it let the community focus going energy forward. A retired library shall be removed from the main boost project master branch for the next release.  At some point in time, retiring libraries that is proper in the standard may make a lot of sense. Likewise libraries that are missing active maintainers after a waning and grace period of some releases, may make a lot of sense to retire in this way.

Note that I am just airing out some wild thoughts here that may be of use, thus be gentle but firm in comments.  Discuss, shoot down, or ignore as you wish.  I expect some might think this is crazy.  Just to be clear, I see the backside of this as I am a boost user in a company which likely will need to do more work and possibly contribute with LTS forks if this happens as outlined above.  However I am sure the more important concern is to let Boost focus on its mission as a breeding ground for new ideas and features in C++.  For users to be held back some versions on boost is normally not that big of a deal in the cases where you cannot use the latest compiler with the latest language support any way.  At least I think so,  hopefully not my famous last words… 

Best regards to you all,
—
Bjørn