Establish predictable removal policy for end-of-life Python versions

[EwoutH]

With cibuildwheel maturing, I think it would be good to establish a predictable removal policy for end-of-life Python versions. This allows everyone to anticipate the end of wheels for that version, and move on.

Dropping end-of-life Python versions at some point would:

• Reduce maintenance burden
• Reduce the CI and network burden on the environment 🌳
• Signal that the it's time to move on

Of course, with cibuildwheel dropping a Python version, projects that really need beyond end-of-life Python wheels could always keep using an old cibuildwheel version. And existing wheels are still on PyPI after a new cibuildwheel release without support for the EoL version.

My suggestion for a schedule would be something along the lines of:

• 3 months after EoL: Stop building wheels by default
• 9 months after EoL: Drop support

With the new 1-year release cadence this would ensure a few cibuildwheel versions in which the end-of-life Python version could be build together with the brand new one. And with 9 months it would be removed before the next one.

Practically, that would look like this:

Timestep	Python 3.6	Python 3.7	Python 3.8	Python 3.9
End-of-Life	2021-12-23	2023-06-27	2024-10-14	2025-10-05
Stop building by default	2022-03-23	2023-09-27	2025-01-14	2026-01-14
Removing support	2022-09-23	2024-03-27	2025-07-14	2026-07-14

Which would mean for Python 3.6, a one-time catch-up is needed. Then from Python 3.8 onwards, stop building by default in January and drop support in July (just before the release candidate of the next version).

The exact schedule is just a suggestion to start discussion about this. The predictability of the schedule is most important. Curious what everybody thinks!

[henryiii]

We follow manylinux. Manylinux follows EoL's for Ubuntu. So Python 3.6 will be removed in April 2023 when Ubuntu 18.04 hits EoL.

We don't have a "default" vs. "can't build". We build everything that's native by default (including musllinux!). It's not clear how you could expand this to have a "non default but still can build" feature without really complicating the system.

I do think it might be nice to pull the available versions from manylinux containers, so the drops really would be entirely based on manylinux dropping things, and pinning an older image would allow you to build older Pythons. That would get out of sync for the others, though.

IMO, cibuildwheel should not be in the place of forcing the ecosystem to drop things. Most users should set a minimum Python version, and cibuildwheel already respects that. Because it happens to build 3.6 doesn't mean you need to or should be supporting 3.6. We dropped previous versions because they required significant effort to support and because manylinux dropped them.

[joerick]

I agree that because support in manylinux is a hard requirement for cibuildwheel, we can't meaningfully deviate from their schedule. So the debate around when to actually drop support would take place there. And I'm a big fan of keeping things consistent across platforms, so we'd drop support on mac/windows at the same time as linux.

As for 'not building by default' after EoL+3 months, I'd actually be in favour of this, for the reasons you mention. And I'd add another - a user that's setting up wheel building for a new package is unlikely to want to build for old versions of Python, but the fact that cibuildwheel does so by default implies that it's best-practice to build old versions. But, at the same time:

• it does seem hard to add such a feature in a way that doesn't add too much complexity to the options (as henry notes above).
• most users probably do/should set requires-python such that this doesn't happen accidentally - honestly, this is probably the Right Way™ to go about it, and perhaps we should signal this more.

[joerick]

Let's stick with our existing policy of following manylinux, for the reasons noted above.