[boost] [container][interprocess][intrusive][move] Removing support for old compilers

Subject: [boost] [container][interprocess][intrusive][move] Removing support for old compilers
From: Mike Dev (mike.dev_at_[hidden])
Date: 2018-10-01 20:45:20

As you probably know, I'm not a boost library maintainer myself, but have 
been pushing for boost to shed old cruft (e.g. dropping c++03 support in 
boost completely), so take the following with a grain of salt:

> -----Original Message-----
> From: Boost <boost-bounces_at_[hidden]> On Behalf Of Ion Gaztañaga via Boost
> Sent: Monday, October 1, 2018 3:59 PM
> 
> [...]
> 
> I've reviewed some popular long support Linux distributions:
> 
> -> RHEL 6 uses GCC 4.4.
> -> SUSE Linux Enterprise Server 11 Service Pack 4 (SP4) uses GCC 4.3
> 

As Andrey said, I wouldn't be too concerned with old enterprise distros.
The users that do want to use new boost releases on those distributions 
actually have supported access to more recent toolchains via sdks/development
tools. Personally I would focus on the default compiler versions on 
distributions that are still within their regular support period when you 
actually drop the support. (E.g. SUSE LES 11 will enter extended support
on April 2019, so I'd rather look at SUSE LES 12 and RHEL 7 for the same
reason)

Don't forget the pipeline delay here: 

- You probably want to give a warning that compiler version X.Y will no 
  longer be supported in boost version 1.W one or two releases in advance
  (1.W-1 or even 1.W-2 ).
  
- When boost 1.W is released, it will take some time until it is made 
  available to the developers writing applications for those platforms 
  (e.g. due to company internal testing and upgrade cycles)

- The user of your library might have a release cycle of their own 

- Finally, the user of the application using boost 1.W will have an upgrade
  cycle of their own an probably not employ the new software version the 
  day it is released.

This is of course the worst case scenario and it depends e.g. on whether
your library is used in an in-house application or a sold software product,
but there may easily be 1-x years between the point that you decide you 
want to drop support for toolchain version X.Y and the point when an
application using your library actually would be deployed on a production 
system using that toolchain.  

Finally, boost is open source and free - if a company really wants to use 
a long-outdated c++ toolchain with the latest version of boost, they can 
pay someone to implement the necessary workarounds. So unless you are 
getting payed to support those libraries, you don't have to feel too bad
if you make your life a little easier.

If supporting gcc4.4 or VS2008 doesn't cost you much time and effort: Great! 
Keep supporting them! Otherwise, better switch to something more recent
and invest the saved time on new features, other improvements or just life 
with your family.

Best

Mike