Update default image away from manylinux2014 about cibuildwheel

[dralley]

And also, although this is a separate issue, decide on a timeline for dropping support for manylinux2014 from other ecosystem tools (probably not soon, but still, dates should be decided and communicated in advance).

[henryiii]

FYI, manylinux1 and manylinux2010 were supported well past CentOS EoL, in fact manylinux1 is still receiving automated updates and is still supported in cibuildwheel (CentOS 5). 20% of systems cannot support manylinux_2_28 (https://mayeut.github.io/manylinux-timeline/), based solely on the GLIBC version (you also need a recent pip version, which might limit it further). 70% of projects still distribute manylinux2014 wheels.

So while this might change, I don't think it's likely to until after the EoL deadline. (That might help it start to change).

[EwoutH]

We could also do it conditionally, based on Python version. So for example, practically all Python 3.12 consumers support glibc 2.31 or higher. Almost all Python 3.11 consumers support 2.28 or higher.

So you could end up with something like:

• Python 3.6-3.9: Default to manylinux_2_17 (== manylinux2014)
• Python 3.10: Default to manylinux_2_26
• Python 3.11: Default to manylinux_2_28
• Python 3.12: Default to manylinux_2_31

Of course this needs to be properly announced, and maybe some policy for instated to update those numbers.

[joerick]

Hmm..! Nice idea, downside would be that it is a bit wasteful in time and bandwidth, as a default. Much of the time of a build is downloading the container, plus, some users do heavy stuff in before-all, which would be done many times for such a setup. Plus, most users don't really need the newer standards - manylinux2014/2010/1 are by far the most popular options today. https://sourcegraph.com/search?q=context:global+%28CIBW_%29%3FMANYLINUX%5B_-%5DX86_64%5B-_%5DIMAGE&patternType=regexp&sm=0

[joerick]

a great reference here is @mayeut's manylinux timeline

[mayeut]

As @joerick said, it's likely just a waste of resources to change the default conditionally on the python version and, users can already do that if they want(/need) to using overrides.

With the current stats for non-EOL python versions, I'd say a good time to change the default could be after AmazonLinux 2 EOL (2025-06-30, I think that's most of GLIBC 2.26 downloads) or Python 3.9 EOL (2025-10-31).

[EwoutH]

I think we can already safely go to 2.26 as the new default.

The fact that 2.17 (==2014) is so much used, is not because target systems don't support better, it's simply because it's the current default.