Re: [boost] Let's discuss dropping support for msvc <= 9.0 (2008), gcc < 4.6, clang < 3.4

Subject: Re: [boost] Let's discuss dropping support for msvc <= 9.0 (2008), gcc < 4.6, clang < 3.4
From: Edward Diener (eldiener_at_[hidden])
Date: 2018-12-13 03:16:27

On 12/12/2018 9:53 AM, James E. King III via Boost wrote:
> During the Boost 1.69.0 release there was a regression on Visual Studio
> 2005 (msvc-8.0).  Microsoft ended support for msvc-8.0 on December 4,
> 2016.  I was going to argue we let it happen, but it wasn't the right time
> to discuss that sort of change.
> 
> Boost has a very large compatibility matrix which increases the effort
> required, and sometimes limits solutions development, to get out a quality
> release.  The boost project as a whole agreed in summer 2018 that if
> repository maintainers wanted to drop C++03 support per repository to make
> substantial improvements or simplifications, or to ease maintenance then
> they are able to do so.  *Folks who need support for older language levels
> and older compilers can always download an older version of Boost.*
> 
> The compilers I mentioned in the subject have trouble with C++11 and are no
> longer maintained.
> 
> msvc-8.0 (Visual Studio 2005) ended support Dec 10 2016
> msvc-9.0 (Visual Studio 2018) ended support April 10 2018
> The last release of gcc 4.6 was April 12, 2013
> The last release of gcc 4.5 was July 02, 2012
> The last release of gcc 4.4 was March 13, 2012
> The compilers by default in Ubuntu Trusty 14.04.5 LTS, supported through
> April 2019, is gcc-4.8, currently at gcc-4.8.2, and clang 3.4 (however
> clang-3.8 is available).
> 
> My argument is that this is a huge project, and maintaining backwards
> compatibility is not always efficiently possible.  We spend build matrix
> resources testing and analyzing those tests.  We find and develop fixes and
> workarounds.  In some cases we hobble potential solutions to cater to
> decade-old compilers.
> 
> Given the summer 2018 discussions about language level, and the aging
> vendor support matrix, I'd like us to consider dropping support for msvc <=
> 9.0 (2008), gcc < 4.6, clang < 3.4.  What does this mean exactly?
> 
> 1. We no longer test these compilers in the post-commit build matrix.
> 2. We no longer test these compilers in continuous integration.
> 3. We no longer develop fixes for issues that affect these compilers.
> 4. We are allowed, over time, to remove workarounds for these compilers.
> 5. We no longer block releases due to incompatibility with these compilers.
> 6. We remove these compilers from the documented environments in the
> release notes.
> 7. We direct anyone looking for support of these compilers to download a
> previous release of Boost that given them that support.
> 8. We do not update older Boost releases to fix issues with older compiler
> support.
> 
> What would we remove from the release notes as a result?
> 
> primary:
>    linux:
>      clang:
>        c++03: 3.0
>        c++0x: 3.0
>        c++11: 3.0, 3.1, 3.2, 3.3
>      gcc:
>        c++03: 4.4.7, 4.5.3
>        c++0x: 4.4.7
>    windows:
>      gcc:
>        c++03: 3.4.5, 4.1.2, 4.2.4, 4.3.3, 4.4.0, 4.5.4
>      msvc:
>        - msvc-7.0 (Visual C++ 7.1)
>        - msvc-8.0 (Visual Studio 2005)
>        - msvc-9.0 (Visual Studio 2008)
> additional:
>    linux:
>      clang:
>        c++03: 3.0, 3.8.1, 3.9.1, 4.0.1
>        c++0x: 3.0
>        c++11: 3.0, 3.1, 3.2, 3.3
>      gcc:
>        c++03: 4.4.7, 4.5.3
>        c++0x: 4.4.7
>    windows:
>      gcc:
>        c++03: 3.4.5, 4.1.2, 4.2.4, 4.3.3, 4.4.0, 4.5.4
>      msvc:
>        - msvc-7.0 (Visual C++ 7.1)
>        - msvc-8.0 (Visual Studio 2005)
>        - msvc-9.0 (Visual Studio 2008)
> 
> The release notes section on compiler compatibility should probably be
> updated to match the current state of the post-commit matrix and duplicates
> in the "additional" section that are present in the "primary" section
> should be removed, or simply merge them.  Why do we have a distinction here?
> 
> Thanks for your consideration,

I do not think that Boost in general needs to support gcc prior to 4.8, 
vc++ prior to VS2010, and clang prior to 3.8. If there are people still 
using gcc-4.6, VS2008, or clang 3.7, tough luck to them. There are tons 
of releases for each compiler after these old versions and they are all 
much better than what came before them. Giving only the major/minor 
release numbers for versions we could support:

For gcc there is 4.8, 4.9, 5.1, 5.2, 5.3, 5.4, 6.1, 6.2, 6.3, 6.4, 7.1, 
7.2, 7.3, 8.1

For vc++ there is 10.0, 11.0, 12.0 14.0, 14.1

For clang there is 3.8, 3.9, 4.0, 5.0, 6.0, 7.0

The problem is always the same. We have long discussions about what 
Boost should support and the answer is always that individual libraries 
can support what they want but no general direction can be decided. I 
put the blame for this on the Boost Steering Committee, which seems to 
me does little or no steering at all. We went through this about 
"dropping support for C++03" and even though there was a consensus about 
what this meant nothing was done, as evidenced by a real case of 
dropping support for C++03 ( Parameter ) where it was suggested not to 
do it. We got the whole treatment about supporting CMake without any 
real decision ever being made about what supporting CMake actually 
means. We will do the same here and I am pretty sure that nothing will 
be done other than that each library will do what it wants and the 
regression testers will do what they want.

My point is that we can discuss these issues of support ad nauseam but 
until there is someone with authority to make a decision who actually 
makes a decision, nothing will be effected. My personal viewpoint is 
that while a particular library can support what it wants, someone 
should have the power to suggest a general direction about Boost and 
what it should support at the minimum. Then individual libraries can 
decide to support more if they want. But I do not ever see this 
happening because those who have the authority to do so do not seem as 
if they will ever do this. I do not mean to be critical or negative but 
we have been through this before, to very little purpose.

> 
> Jim