Supported CPython releases

[jaimergp]

Consolidates discussion in conda-forge/conda-forge-pinning-feedstock#5013

The general rule @conda-forge/python team follows is:

CPython 3.X is supported until EOL or until Python 3.(X+5).rc1 is released (and packaged) whichever comes first.

Since PEP 602 (2019), the Python release cadence is annual, with five years of support. This means that, since Python 3.8, October is the month where old versions go EOL and new versions are published. RCs are usually published around April/May.

Taking into account that the RC needs some time to be packaged in conda-forge, users can expect the python pinning matrix to be updated somewhere in Summer every year. This is of course a guideline with no guarantees and subject to the availability of volunteer efforts.

Check the Status of Python versions docs for more information about the Python release cycle.

[jakirkham]

Thanks for opening this Jaime! 🙏

I don't think we quite reached a decision. Though this was certainly a proposal with some support

CPython 3.X is supported until EOL or until Python 3.(X+5).rc1 is released (and packaged) whichever comes first.

Think the real constraint is when we start migrating for a newer version. That seems like the time to drop the older version

Taking into account that the RC needs some time to be packaged in conda-forge, users can expect the python pinning matrix to be updated somewhere in Summer every year. This is of course a guideline with no guarantees and subject to the availability of volunteer efforts.

Would additionally caveat this with CI resource availability

[jaimergp]

Feel free to edit the issue as needed (same goes for any core member or python-feedstock maintainer!), I just wanted to get the ball rolling here after being reminded of that conversation in a Zulip thread today 😊

[jakirkham]

Would rather we comment so it is a little clearer who is saying what

Once things settle down we can try to coalesce the statement of intended support

[h-vetinari]

CPython 3.X is supported until EOL or until Python 3.(X+5).rc1 is released (and packaged) whichever comes first.

This is close enough that I thought "obviously", but John's right. It's not when we package the rc, but when we kick off the migration.

users can expect the python pinning matrix to be updated somewhere in Summer every year.

So far we've begun migrating twice before the actual GA (3.12 & 3.13), and in both cases it wasn't before September (well August 28th for 3.13 if we're pedantic). Given that rc1 is scheduled end of July and rc2 end of August, I think it's most realistic that we await rc2 and then migrate. So I'd write this as "in or around September every year".

[jaimergp]

From our discussion in the last core meeting, things to do here:

• Update text to mention "start of migration" as the key event for the drop
• Mention patch maintenance policy too (not being in the pinning matrix does not imply lack of support til EOL, provided resources are available)

[hmaarrfk]

One big challenge for me with python is the use of the zip. I think we can do steps to remove it entirely in 2025
conda-forge/conda-forge-pinning-feedstock#7474 is a first step.

[h-vetinari]

One big challenge for me with python is the use of the zip.

Can you explain what tasks/actions are challenging? Interrelated pinning metadata as a fundamental need is not going away. I find the mechanism pretty straightforward, the only real painpoint from my POV is not being able to extend a global zip with extra keys locally (we already have infrastructure in smithy to do that for migrators, but not in a regular CBC).

[hmaarrfk]

real painpoint from my POV is not being able to extend a global zip with extra keys locally (we already have infrastructure in smithy to do that for migrators, but not in a regular CBC).

this. Generally any kind of "if/but statement" is a barrier to entry to new programmers and "context" that I have to maintain in my mind.