Plan for cibuildwheel 4.0

[henryiii]

I'd like to propose the following:

• Drop pyodide wheels and pyodide 3.12, only make pyemscripten wheels for 3.13 and 3.14 (alpha pyodide) Pyodide updates: pyemscripten platform tag (PEP 783), 314.0a1, pyodide-eol flag, and maintenance updates #2812
• Drop Python 3.8 break: drop Python 3.8 #2686
• Drop Python 3.13t Drop python3.13t #2684
• Auditing Audit - general approach to auditing wheels with abi3audit default #2805
• feat: add CPython 3.15 beta 1 #2833
• Maybe Linux pinning in test environments #2822?
• delvewheel as default for windows repair command #2803, coming via Set up delvewheel as the default repair wheel command for Windows #2831

Some assorted changes/fixes included too, those are just the main things.

3.15 and manylinux removing stuff will hit in about a week (5-5-2026), so shortly after that we could release what I'm proposing to call 4.0, due to the fairly big drops and pyodide -> pyemscripten change.

Maintainers, feel free to edit directly. Anyone can comment.

[agriyakhetarpal]

Since we're considering an audit command to land, let's also consider adding delvewheel as a default Windows repair command, as @joerick is interested in doing so in #2803 (comment). I am too. Users can still disable it, obviously. The only problem I can think of with that happening is the things we can't control on the GHA runner + MSVC combo's side, see adang1345/delvewheel#54 for an example. But that's fairly old, and was resolved quickly, so most likely not a big problem.

I'm happy to work on this if you also think it's good to add. 😄

I would also say we could drop support for macOS Intel, but that's a 🌶️ change and we might need some numbers before we do that.

[henryiii]

I'd say yes for windows repair.

For macOS, if 3.15 supports Intel, we should too, otherwise it will be hard to build Intel wheels. This year major Intel runners go away, though, so that's probably when we will be likely to drop too. We could make Intel runners deprecated in 4.0, though, so we have a bette excuse to drop them without a major bump, probably near the end of the year.

About a week ago I got my new laptop and am no longer often on an Intel Mac. :)

[agriyakhetarpal]

Okay, great. Let's mark macOS Intel as officially deprecated. It looks like the macos-15-intel runner disappears next year in Fall 2027, so we could run CI on them until then.

Congratulations on your new laptop! I hope you enjoy it!

[xavier2k6]

There are macos-26-intel runner images available:

• https://github.com/actions/runner-images#available-images

Most likely it will match dates from macOS-14 plus two years: [macOS] The macOS 14 Sonoma based runner images will begin deprecation on July 6th and will be fully unsupported by November 2nd for GitHub Actions and Azure DevOps

Which means July 2028 as deprecation point and November 2028 as decommission date. But we'll monitor the situation. The dates may change slightly. It's possible a decision will be made to keep the image in a deprecated state for a little longer to give Intel users more time.

actions/runner-images#13739 (comment)

[xavier2k6]

Note:

Partner provided image of windows-11-arm, can probably be replaced soon with official windows-11-arm64 image when announced/released.......WIP.

Xref.: actions/runner-images#13975

[agriyakhetarpal]

Thanks for the links @xavier2k6! Then I think it's more reasonable to keep macOS Intel in cibuildwheel – especially because the ecosystem will stop building macOS Intel wheels before we do. The maintenance burden isn't high at all and would just diminish over time. I guess the time when Python will drop macOS Intel builds is when we should, too.

[joerick]

Quite a lot to get in here! Depending on how easily the PRs land, one option could be to release an alpha or two with the 3.15b1 included, since I know there'll be some early birds eager to test with that :)

I think it'd be fine to use the main branch to put this together, I doubt we'll be doing much on v3.x in the meantime.