Repository navigation
Decide on a Python version support policy #362
Description
What needs to be done?
It would be good to decide and document which versions of Python to support. The two options here seem to be:
- All currently supported Python versions (currently 3.8 - 3.12)
- All Python versions supported by Scientific Python Ecosystem Coordination 0 (currently 3.10 - 3.12)
Activity
dstansby commentedon Apr 25, 2024
I'm happy for either - I see the arguments for only supporting newer versions (#359 (comment)), but also don't think there would be much more burden in supporting older but-still-security-patched versions.
samcunliffe commentedon May 9, 2024
Half-vote for keeping 3.9 🗳️. (I guess that's option 1.5 🙃 )
dstansby commentedon May 9, 2024
I'm 👎 👎 having an ad-hoc approach where we decide a list of versions we support on a rolling basis, instead of following an existing policy that decides for us.
samcunliffe commentedon May 9, 2024
Wait, 3.8 is EOL, no?Nope. 3.8's EOL is 2024-10 so option 1 will become what I voted for very soon.
paddyroddy commentedon May 17, 2024
I vote 2️⃣
dstansby commentedon May 17, 2024
I'm coming round to 1️⃣ , because I don't think it is much more effort to support more Python versions, and we do work on some projects in ARC that aren't within the scientific python ecosystem (I'm thinking web projects, but maybe there's others?)
dstansby commentedon May 17, 2024
Those advocating for 2️⃣ , what are your reasons?
paddyroddy commentedon May 17, 2024
For me, a few reasons:
3.11then you benefit quickerSPEC 0is endorsed byipython,networkx,numpy,scikit-image,scipy,xarray,zarr3.10was the newest one when it came out. It may not support older versions.dstansby commentedon May 17, 2024
If you do the numbers I think this is very small number compared to e.g., flying to conferences or on holiday or embodied carbon of hardware or electricity usage of a large simulation code. I once etimated that Matplotlib uses ~25 kg/month [png link], and they must be running orders of magnitude more CI than us.
I buy the rest of the arguments though. I think @matt-graham was also pro SPEC 0, so perhaps we give @samcunliffe a bit to explain
from above, and then unless there's a compelling reason go with SPEC 0?
samcunliffe commentedon May 17, 2024
My vote was a soft 1, but very soft. Mostly web/dashboard/other.
If the majority want 2, let's go for it. Less GHA minutes also has cost implications if our users have nonpublic repos. And 🌱 is a good argument.
dstansby commentedon May 17, 2024
👍 I'll leave this open until we document the decision, and merge #360
Document that we conform to SPEC0 version support.
Document that we conform to SPEC0 version support. (#487)
samcunliffe commentedon Nov 6, 2024
Viz #360 (mostly) and #487 (finally).