Remove support for Python 3.8

[zanieb]

I'll fill in some details here, but we should probably simplify the builds by dropping support for 3.8 now that it is EOL. I'm not sure how long we want to support versions after they're EOL, but the build matrix is huge as-is.

[indygreg]

I've historically dropped support (read: stopped publishing and deleted code to build) Python versions once they hit EOL per upstream.

So it is time to remove 3.8 from PBS.

[jbvsmo]

I was on a similar discussion on uv project and it does seems to me that astral and indygreg might have different goals when creating these compiled versions of python.

IMO Astral wants to build a widely adopted toolchain that can install python in as many systems as possible for end users and indygreg wants to have every single variation of a target triplet available for the most recently supported python for modern systems, not necessarily for end users only.

There is a huge overlap, but I see things that does not benefit uv directly here and things that uv would benefit from being dropped. E.g.

Benefit direct users of python-build-standalone but does not benefit uv users:

• debug builds or other non optimized/partially optimized builds
• platforms not supported by uv such as mips or mipsel
• all x86_64 variations such as v2, v3, v4 that are simply ignored for the sake of compatibility

Benefits uv users but does not benefit direct users of python-build-standalone :

• older EOL versions of python such as 3.7 and 3.8 that are still very much in use

The point @zanieb made was that linux build matrix was too complex and took too many hours.

So, I have a few suggestions:

1. Have separated workflows for each version of Python to guarantee they can be triggered independently.
2. Make slim and wide releases where slim means only optimized builds for platforms supported by uv.

I would suggest that uv have a fork of this project on the Astral org where they can run the slim version of the workflow for more python versions (e.g. 3.7-3.14) and indygreg can continue running the wide version but for fewer python versions (e.g. 3.9-3.13).

That way you can have a single code base by keeping the forks in sync but each triggering the release mechanism with different parameters.

So what this means for this issue?

Don't drop the python 3.8 code, please

[zanieb]

As I mentioned in the linked discussion, I don't think that separating the builds helps; we need to continuously test to ensure we're not breaking things. Only running 3.8 builds in a fork means we'd end up doing more work to incorporate upstream changes — I don't think that's a great outcome.

As a side note, I plan on adding support for debug builds in uv and I think there's been a request for x86_64 variant support. Those builds aren't useless for uv users.