On Wed, Dec 12, 2018 at 3:54 PM James E. King III via Boost wrote:

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?

Why <= for msvc and < for the others? ;) -- Olaf

Wouldn't dropping gcc 4.6 drop support for RHEL 7.x?  That might cause some off-the-wall problems for some users.  Can anyone speak to this with any more knowledge? On 12/12/18 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,

Jim

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

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