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

Subject: Re: [boost] A possible date for dropping c++03 support
From: Paul A. Bristow (pbristow_at_[hidden])
Date: 2018-08-28 11:24:54

> -----Original Message-----
> From: Boost [mailto:boost-bounces_at_[hidden]] 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