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

Subject: Re: [boost] A possible date for dropping c++03 support
From: Tom Kent (lists_at_[hidden])
Date: 2018-08-27 21:49:35

On Sun, Aug 26, 2018 at 11:19 AM Mike Dev via Boost <boost_at_[hidden]>
wrote:

>
> - I'm somewhat expecting Windows to be the more problematic environment as
> msvc
>   only got full c++11 support in 2015 (at least as far as you can call
> msvc
>   standard conformant prior to the very latest version anyway) and
> extended
>   support for 2013 ends in 2024.
>

To confuse the problem even more, just like other compilers, there is no
version that can easily be pointed to as having full C++11 compatibility.
2015 is probably the closest, but still has a few missing features:
https://msdn.microsoft.com/en-us/library/hh567368.aspx
Actually, just one "Expression SFINAE".

However, for some uses even VS2010 might have sufficient C++11 support...if
all you need is auto and shared_ptr.

I think in general the question is:
> How many projects will there be in 2020 that (for whatever reason) still
> need to
> compile in 03 mode, but at the same time are interested in the latest
> version of
> boost? I'd expect that intersection to be very small, but of course it
> will be
> non-zero - and probably remain so for at least another decade (maybe
> forever).
>
> Maybe one could start survey, but in any case: does boost really want to
> provide
> free and indefinite support for those projects considering that
> maintenance is
> already a problem for some libraries?
> And again: Projects outside of boost can always opt to remain at the last
> version that had official 03 support.
>

TL;DR
 - We need to be more supportive of end-users needs, they're the (silent)
majority
 - Publicize with the 1.69 release, that libs can drop C++03 support at any
time
 - Support future 1.68.X releases if security issues (only!, no bugfixes)
are ever discovered

I think this is the more important question. I'm with many users of this
list, in that I want to push forward and have C++ be a beautiful, modern
language. Unfortunately then I show up at my day-job and am faced with
reality. We still have huge code bases that are incredibly resistant to
change :-(   I feel like it should be a trivial matter to roll the compiler
version....but it is not. We've long depended on boost as a forcing
function to get modern practices into our codebase. We have (some of the
time) rolled to newer versions to get new features. And crucially to this
discussion, we like having one boost version across multiple
projects...some of which are using C++11 compliant toolsets, some aren't.

In general, I think this list is *far* too biased towards the developers of
boost and not attentive enough of the silent majority of users who aren't
active here. For a point of view, the 1.67 release had 76,180 downloads in
July from bintray. Compared to the few dozen people active on this mailing
list. If even (only) half of those are bots/duplicates...that's still a lot
of un-represented interest. Likewise the binary build for VS2008/32-bit
still has 23 downloads in the last week on Sourceforge (Bintray doesn't
provide per-file statistics, but since the availability of the of the
sourceforge files isn't publicized on the website, is surely higher). These
23 sad souls had to go track down this binary and manually download it.
They are almost certainly not bots or just people grabbing all the binaries
just because....there are other downloads on that page with 0-5 downloads.

All that said, (with my C++ fan hat on) I don't want to hold back boost
growth by keeping it saddled with crucial libraries that are stuck in C++03
mode...and fully support new libraries being C++11/14/17/2a only. I think
that from the next release forward, we should make it clear in the release
notes that existing libraries may be dropping C++03 support at any time
without advanced notice (although it would be nice if some of the core
libraries gave specific notice of this 1+ releases early, so it can filter
down through libraries that may depend on them). This will let users know
that they need to be extra careful with updates if they are still C++03.

Additionally, it would be good to publicize that the 1.68 release will be
the last release with broad C++03 support (minus libraries that never
supported it). So it is clear for non-c++11 projects which version they
should choose. Additionally, if we encounter security vulnerabilities going
forward, I think it would be good that we be able to roll future versions
of this "last" C++03 release e.g. 1.68.1. To my knowledge we've never had a
minor release to a previous version after the next version (e.g. 1.69) was
released, so this would be a new thing....and may require some (minor?)
changes to the release tools. This should be for true security fixes only,
no backporting bug fixes!