Supported versions

[geofft]

I'm looking at the list of patches and other build-time workarounds in python-build-standalone and several of them apply solely to older Python versions. We build for all supported releases, which at the moment still includes 3.9 but is presumably being dropped soon, up to the development release (currently 3.15). There's a lot of stuff that's been redone in better ways in more recent versions than 3.9, and some of the patches to older versions feel unsuitable for the stable branches. (I can prepare a list of these if that's helpful.)

I would like to raise the proposal that this project target Python versions 3.15 onwards, where we can land things into the main branch. Once a release is out, it makes sense to support it for its full security lifecycle, but I'm not sure that carrying patches to older versions is worth the time investment.

What do other people think?

[brettcannon]

We don't do binary builds all the way until EOL, only the first (roughly) 2 years until security-only releases occur. Whether we change that policy is a much bigger discussion with the release managers and the Python core team (i.e. it isn't specific to this project as we already have a policy due to the Windows and macOS installers).

As for whether we would backport or not, I'm not worrying about that yet. We need to get this working for main first, then we can see what it would take to go backwards.

BTW, this is why I expect there to become some make target in main so that we can always make sure things work with the code itself instead of separate and thus having to make it work across Python versions.

[hugovk]

only the first (roughly) 2 years until security-only releases occur

Exactly two years:

https://peps.python.org/pep-0602/#years-of-full-support-3-more-years-of-security-fixes