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