feat: remove Python 3.7 support

[rwgk]

Description

WIP

Suggested changelog entry:

[rwgk]

Overview of all compiler versions used/lost(-)/gained(+) before this PR, and with this PR @ commit 2f24de5:

• Clang release dates: https://releases.llvm.org/

• GNU release dates: https://gcc.gnu.org/releases.html

 AppleClang 15.0.0.15000040
-Clang 3.6.2    16 Jul 2015
-Clang 3.7.1     5 Jan 2016
-Clang 3.9.1    23 Dec 2016
 Clang 5.0.2
-Clang 7.1.0    10 May 2019
-Clang 9.0.1    20 Dec 2019
-Clang 10.0.1    6 Aug 2020
 Clang 11.1.0
 Clang 12.0.1
 Clang 13.0.1
 Clang 14.0.6
 Clang 15.0.7
 Clang 16.0.6
 Clang 18.1.6 with GNU-like command-line
 Clang 18.1.7
 Clang 19.0.0
-GNU 7.5.0      November 14, 2019
-GNU 8.3.0      February 22, 2019
 GNU 8.5.0
 GNU 9.4.0
+GNU 10.2.1
 GNU 10.5.0
 GNU 11.4.0
 GNU 11.4.1
 GNU 12.4.0
 GNU 13.2.0
 GNU 13.2.1
 GNU 13.3.0
 Intel 2021.10.0.20230609
 MSVC 19.29.30154.0
 MSVC 19.40.33811.0
 NVHPC 23.5.0

[rwgk]

Tracking simple findings:

• ubuntu-18.04 apt-get update && apt-get install -y gcc produces g++ (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0, BUT ubuntu-18.04 is not longer available: The Ubuntu 18.04 Actions runner image will begin deprecation on 2022/08/08 and will be fully unsupported by 2023/04/03 actions/runner-images#6002

• ubuntu-20.04 apt-get update && apt-get install -y clang produces clang version 10.0.0-4ubuntu1

[henryiii]

I think this next release might be a good time to remove C++11 support and increase our minimum supported compilers.

[rwgk]

I think this next release might be a good time to remove C++11 support and increase our minimum supported compilers.

Awesome. That's what I was thinking, too. I'll work on this PR more after the 2.13 release has baked in a bit.

[henryiii]

I think we can also bump CMake support. Personally, I've been going 3.15+ everywhere as that is what was required to build scikit-build-core. Though another option is 3.12+ (FindPython). I think we has someone request 3.10 or 3.11 before, might be worth checking.

If we did go 3.15+, we maybe could start to phase out classic FindPythonInterp support.

[rwgk]

If we did go 3.15+, we maybe could start to phase out classic FindPythonInterp support.

I just looked up: CMake 3.15.0 publication date was 17 July 2019

Does that look correct? — That's already 5 years ago (almost at least), and before Python 3.8 was released (Oct 2019). — I think it's much more likely to be helpful than harmful to make CMake 3.15 the minimum, and shed cruft.

[henryiii]

Here's the support table for CMake, with darker red for older than 3.15:

[rwgk]

My thinking:

• I want to wait about one week, JIC we need more 2.13 patch releases.
• Then I'll make a fresh pass through this PR, looking for 3.7 and 3.8 version numbers of all sorts once more.
• Then merge this PR, documenting in the PR description that we're losing testing with Clang 3.6 through 10, and GCC 7 as a consequence of dropping Python 3.7 support, but we're deliberately deferring cleaning up ifdefs for another release.
• Then have a follow-on PR to bump the cmake minimum to 3.15 (independently from dropping Python 3.7) and clean out cmake cruft.

[henryiii]

We’ve already made a 2.13 branch, master is 2.14. No rush, but waiting isn’t required. Does save ci time though if the branches are functionally identical.

No need to defer cleanup, we have plenty of time for this to sit in master. We should specify and test minimum versions where possible. I’m hoping we get a MSVC bump. :)

But that can also be a follow-up.

[rwgk]

but waiting isn’t required.

it more prioritizing than waiting

this is up high on my list though; not a lot more to do