Create a process for releasing a wheel for a new Python version with a previous sklearn version on CI

[thomasjpfan]

For version 1.5.2, the wheels were not updated from the CI, but from an API key. Moving forward, I think we should update our CI to allow us to push specific python versions. I propose this process:

1. Prerequisite: Python 3.14rc support added to cibuildwheel + numpy & scipy has wheels for it
2. Update build_tools/cirrus/arm_wheel.yml and .github/workflows/wheels.yml to support the new version on 1.X.X branch
3. Trigger .github/workflows/publish_pypi.yml (workflow_run) with a specific python version which will only upload wheels for that python version.

These are the tasks I see:

• Required: Update .github/workflows/publish_pypi.yml to accept a specific python version and only upload that python version.
• Nice to have, but not required: build_tools/cirrus/arm_wheel.yml and .github/workflows/wheels.yml to only build wheels for a specific python version.

CC @lesteve

[lesteve]

Just to say I have seen this, I agree would kind of be nice to have a less manual process than what we did for Python 3.13, but (managing expectations) I am not planning to work on it in the near future 😅. Next time we will need this is likely September 2025 to prepare for Python 3.14 release.

Your plan sounds reasonable, here are my current thoughts:

1. is generally is doable and we kind of do it already. This generally means relying on numpy and scipy development wheel which complicates temporarily the CI scripts and can be a bit more brittle than using released versions but that's probably fine.
2. is probably the most time-consuming, because the CI may have been updated in main and you may need a bit of work to back-port everything in your release branch. This may be less painful for wheels since they don't use lock files but there could still be a few conflicts to solve. The good thing is that it is probably a lot less painful that doing a bugfix release only to have wheels for the soon to be released Python version.
3. seems doable, do we want some input about the number of wheels you are expected to upload as a sanity check to prevent mess-ups? You only have one shot at uploading a Python 3.14 wheel for a given Python version + OS + ABI tags, so if you mess something up you probably need to do a new bugfix release ¹. Maybe there is a special case for free-threaded, if you say Python 3.13 do you mean free-threaded too, could there be some free-threaded related issues. Probably YAGNI, but I imagine you could type something like cp314-cp314- if you explicitly want only vanilla CPython 3.14 wheels and cp314-cp314t- if you explicitly want CPython 3.14 free-threaded only.

Footnotes

1. or use the pip build number but apparently that was painful to use last time Olivier did it ↩

[thomasjpfan]

do we want some input about the number of wheels you are expected to upload as a sanity check to prevent mess-ups

We currently use https://github.com/scikit-learn/scikit-learn/blob/main/build_tools/github/check_wheels.py which computes the number of expected artifacts. If we can get this working with a specific python version (or tag prefix), then I'll prefer that.

[sayfnkaewkhunthd-ctrl]

For version 1.5.2, the wheels were not updated from the CI, but from an API key. Moving forward, I think we should update our CI to allow us to push specific python versions. I propose this process:

1. Prerequisite: Python 3.14rc support added to cibuildwheel + numpy & scipy has wheels for it
2. Update build_tools/cirrus/arm_wheel.yml and .github/workflows/wheels.yml to support the new version on 1.X.X branch
3. Trigger .github/workflows/publish_pypi.yml (workflow_run) with a specific python version which will only upload wheels for that python version.

These are the tasks I see:

• Required: Update .github/workflows/publish_pypi.yml to accept a specific python version and only upload that python version.
• Nice to have, but not required: build_tools/cirrus/arm_wheel.yml and .github/workflows/wheels.yml to only build wheels for a specific python version.

CC @lesteve