Proposal: Zarr-Python should adopt the Scientific Python spec for minimum supported versions

[jhamman]

It would be nice if Zarr-Python had a clear process for determining what the minimum supported versions of various dependencies were. The Scientific Python project developed a spec for just this purpose: https://scientific-python.org/specs/spec-0000/. The relevant part for us is when to drop support for old versions of Python and Numpy. The spec defines support windows as:

1. Support for Python versions be dropped 3 years after their initial release.
2. Support for core package dependencies be dropped 2 years after their initial release.

So three years for Python and two years for NumPy.

I propose we adopt this spec. In the short term, that would mean we drop support for Python 3.8 and shortly thereafter 3.9. We would also benefit from a CI environment that tests against old version of NumPy and other optional dependencies.

[d-v-b]

Sounds like a good idea to me.

[sanketverma1704]

Hi @jhamman. 👋🏻

Thanks for raising this issue. I've been involved with the good folks over at Scientific Python and added Zarr-Python as one of their core projects and also participating in the SPEC Steering Committee.

Recently, I discussed endorsing SPEC0 with the Zarr Steering Council. We discussed dropping Python 3.8 ASAP (@jakirkham thinks we should have done this earlier) and dropping Python 3.9 early next year.

Since the SPEC0 recommends dropping Python 3.9 in 2023 Quarter 4 - I wanted to check with the folks over at Scientific Python whether it is acceptable to drop the support beyond the mentioned timeline.

Mostly, I think all the active @zarr-developers/python-core-devs are in favour of this decision. But if anyone has any concerns please feel free to raise them here.

Additionally, it'd be great if we finish #1557 soon.

[jni]

I'm also pro-dropping 3.9 ASAP. (And support SPEC0 in general.)

[jhamman]

Thinking about this a bit more I've come up with this perspective:

• Zarr-Python 3 strictly adopts SPEC0 and ships as 3.10+ from the start (even if we manage to release in Q1)
• We keep 3.9 active through Q1 as it is little additional effort and we are not doing much development on 2.* beyond basic maintenance. If 3.0 slips into Q2, then we can drop 3.9.

[jni]

I don't have a lot of skin in this game but this post on real-world match/case by Ned Batchelder made me more excited to start working on 3.10+ codebases. I suspect that there would be plenty of opportunities to use this in zarr-Python.

[joshmoore]

👍 for me, with my only caveat being I think we should decide whether or not this simultaneously applies to numcodecs and if not, what does?

cc: @jakirkham

[sanketverma1704]

Since #1557 is completed, I think we should formally endorse SPEC0 alongside other projects.
Should we do a release before Zarr-Python V3.0 and then adopt SPEC0, or wait until V3.0 and then adopt SPEC0?

Perhaps a discussion on numcodecs during this week's community meeting (1/24) might be a good idea if all can make it.

[jhamman]

Let's make 2.16.2 reflect the current state of Zarr-Python (including 3.9 support). That can likely go out now.

v3.0 will be 3.10+

[joshmoore]

Let's make 2.16.2 reflect the current state of Zarr-Python (including 3.9 support). That can likely go out now.

Can I suggest it should by 2.17 since 3.8 was dropped? Otherwise, 👍

[sanketverma1704]

After a discussion with the good folks at Scientific Python, it was clear that we could endorse SPEC0 before the next release. The SPEC documents are more of a recommendation for scientific projects than bylaws.

Since we already have a consensus among us and after talking to @jhamman and @d-v-b at the Zarr Sprint today and @joshmoore at the community meeting, I've gone ahead and sent a PR to endorse SPEC0 here: scientific-python/specs#299.

Please approve the PR or react with 👍🏻. Thanks!

[jhamman]

@MSanKeys963 - to close this out, would you mind adding a note to the installation docs page noting the version support policy: https://zarr.readthedocs.io/en/stable/installation.html