feat: Python 3.14rc1 build by default

[cibuildwheel-bot]

Update the versions of our dependencies.

PR generated by "Update dependencies" workflow.

[Copilot]

Pull Request Overview

This PR promotes Python 3.14 from prerelease to stable status by default, updating from beta 4 (b4) to release candidate 1 (rc1). The changes include adding cp314 and cp314t to the default build identifiers, updating test expectations, and refreshing Docker image versions.

Key changes:

• Add cp314 and cp314t to DEFAULT_IDS for standard build inclusion
• Update Python 3.14 version from b4 to rc1 across platform configurations
• Update selector logic to treat cp315 as the new prerelease version

Reviewed Changes

Copilot reviewed 9 out of 9 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
unit_test/option_prepare_test.py	Adds cp314 and cp314t to default build IDs and updates test expectations
unit_test/linux_build_steps_test.py	Updates test assertions for additional cp314 build configurations
unit_test/build_selector_test.py	Adds test cases for cp314 platform selection
test/utils.py	Moves cp314 variants from prerelease to default build tags
pyproject.toml	Adds pylint configuration for max positional arguments
cibuildwheel/selector.py	Updates prerelease filter from cp314 to cp315
cibuildwheel/resources/pinned_docker_images.cfg	Updates Docker image versions from 2025.07.20-2 to 2025.07.23-1
cibuildwheel/resources/build-platforms.toml	Updates Python 3.14 URLs from b4 to rc1
README.md	Removes prerelease notation from Python 3.14 documentation

[joerick]

Looks good to me! Not sure what's up with that CI run... but doesn't look like a test failure to me, maybe a platform failure?

[joerick]

I ran the test suite locally on Mac and it was fine. Have restarted it here but it's fine to merge IMO.

[henryiii]

I think it's fine to merge too, the failing part wasn't related to RC1 anyway.

[cdce8p]

Not sure if there was any discussion about it already. Should cp314t really be build by default? I'm not involved enough in the free threading ecosystem to know the current state of things. At least for mypy, I'd probably need to disable the builds manually to get the build pipeline to pass if the PR is merged as is.

The enable = ["cpython-freethreading"] option feels safer at least for the moment.

[henryiii]

Starting with CPython 3.14 beta 3, free-threading is no longer experimental. That means every package should strive to produce free-threading wheels, and they should opt out rather than opt in, unlike 3.13. We only had the enable while it was experimental ("This will enable building these wheels while they are experimental." was the exact quote in our docs). We turned this off in a previous PR #2503, and that’s where you can see the text about this only being true while experimental. https://peps.python.org/pep-0779/

I think it's fine if you have to turn it off, you are explicitly stating you don't fully support all of 3.14. Most binding tools (pybind11, nanobind, cython, SWIG, PyO3, see https://py-free-threading.github.io/tracking/) have supported free threading for quite a while. MyPyC is one of the largest ones that doesn't, I think.

[henryiii]

Also see https://www.python.org/downloads/release/python-3140b3/

[cdce8p]

Yes I did see that it's no longer considered experimental. Though I'd say that mainly applies for cpython itself. Not sure how far along the ecosystem itself is / how challenging it is to get the free threading builds to pass.

I'd suspect this will probably take another year or two, at least.

[henryiii]

Yes, but hopefully this will push people to start supporting it if they aren't already. The next stage will require most packages to support it, and I think the point of declaring it no longer experimental upstream is to signal that you can't just ignore it anymore downstream, which is also what we are also doing by requiring it to be explicitly skipped. Plus we explicitly said the enable was only going to be valid while it was experimental upstream. :)

We used to require PyPy be explicitly skipped, and we still require musllinux to be explicitly skipped, so we have a bit of a history of requiring skips. :)

[henryiii]

Getting free threading working hasn't been that bad, though mostly people like @ngoldbaum and @colesbury have done a hero's share of the work, so maybe I shouldn't claim anything about how hard it was. ;) I'd guess it's not that bad for MyPyC, especially if you just supported 3.14t+, which is a little easier.

[ngoldbaum]

We'd love to chat about adding support for free-threading in MyPyC.

I did the lion's share of the work for NumPy and PyO3 and our team has been involved in updating Cython, CFFI, SWIG and many other packages across the ecosystem. There's also the guide we're maintaining at https://py-free-threading.github.io.

All that to say we've accumulated a fair bit of know-how for this and we'd very much like to help out with MyPyC. In almost all cases we've looked at so far the issues have been more tractable than people initially feared.

[cdce8p]

As I suspected at least for mypy there were quite a few build errors. This is just from a test run: https://github.com/cdce8p/mypy_mypyc-wheels/actions/runs/16496179019/job/46642337801#step:4:4390.

We'd love to chat about adding support for free-threading in MyPyC.

This isn't my area of expertise per se. Feel free to engage on the issue tracker though. I believe this is the relevant issue for it: mypyc/mypyc#1038.

[cdce8p]

To add one more datapoint only because I saw it just now: The dependabot update compatibility for cibuildwheel is at 33% currently. Obviously it's difficult to tell if that's because of 314, free threading or a combination of both.

Anyway the release notes make it quite obvious how to disable it so it isn't really an issue.