-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Tom Kent via Boost Sent: 27 August 2018 22:50 To: Boost Developers List Cc: Tom Kent Subject: Re: [boost] A possible date for dropping c++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
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!
+1 1 Publicize with the 1.69 release, that libs can drop C++03 support at any time.(even though this is old news). 2 Support future 1.68.X releases if security issues (only!, no bugfixes) are ever discovered and 3 Publicize that increasingly libraries will be requiring C++14 and 17, and some are *already* requiring as-yet-unstandardized C++2Z! So plan to keep up. 4 A last release version of C++11, 14, 17 ...will be announced a version(or two) ahead. Or do anything - if only to stop this endless argument to little purpose ;-) Paul