Start Python 3.11 migration with the release candidate

This is a direct continuation of what @xhochy posted in #1499 (only replacing 3.10->3.11):

---

Given the discussion in https://discuss.python.org/t/encouraging-3-10-wheels-on-pypi/10207 and especially in numpy/numpy#19630 I would argue that we should also start the Python 3.11 migration before the final 3.11 release is done. This would also enable us to have as many as possible packages ready on the day of the release. It would also help a lot of downstream projects that use conda-forge as their source for their test environments with providing the necessary dependencies.

How to do this

1. Get a 3.11rc build and upload it to conda-forge/labels/python_rc. By not having the RC on the main label, users will not be able to get Python 3.10 environments by chance, only if explicitly requested.
2. Create a Python 3.11 migration that also adds this channel for Python 3.11 builds
3. Write a script that lists all yet built Python 3.11 builds. This is a safety net if something goes really wrong.
4. Start the migration and work on it
5. Wait until 3.11 is released
6. Build 3.11 final
7. Remove the special channel from the migration

What if things go wrong?

We can easily mark builds as broken. In the case that this really happens, we have built a script as part of step 3. We would simply run this.

Will end-users end up with pre-release Python 3.11 environments?

No, the built packages will be all uploaded to the main channel except the one for Python itself. Thus python=3.11 won’t be solvable until the final release has been built. The packages in CI can be built because there we are adding an additional channel.

What happens if there will be ABI breakage between the RC and the final release?

This is a very unlikely case and as outlined in numpy/numpy#19630 between the RCs and the final release are stricter requirements for changea than between patch releases.

If this still happens, we would simply mark all existing builds as broken using the script from point 3 and restart the migrator.

---

I thought about this because the first beta for 3.11 (the point from which the ABI is supposed to be stable) is going to be released in bit more than a month. At least, we could start iterating on the cpython build at that point.

I was also thinking about the mechanics of the migration a bit - it would IMO not be great to let the migrator work against the main branches of the feedstock (even though the outputs be safely stowed away in conda-forge/labels/python_rc) - this is because the world never sleeps, new versions are released all the time, and this would necessitate reverting the migration work probably quite often, leading most likely to an uncomfortably high amount of churn.

I was therefore wondering if the bot could/should be taught to create a branch python_rc off of main to do such a migration. Since this would conceivably take some time, I wanted to open the discussion a bit earlier already.

[p-r-o-j-e-c-t-1]

Python 3.11 is available today. When could we directly conda install python[version=“3.11”] ?

[h-vetinari]

was this issue closed by conda-forge/conda-forge-pinning-feedstock#3573 ?

Yes, the migration is in full swing, check out https://conda-forge.org/status/#python311. This issue was about something slightly different (starting with the migration already before the actual GA release), but I guess that’s a moot point now.