On Sun, Aug 26, 2018 at 11:19 AM Mike Dev via Boost
- 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!