Boost logo

Boost :

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

Boost list run by bdawes at, gregod at, cpdaniel at, john at