Python version support policy

[wshanks]

Splitting out the discussion from #341: what should the project's policy regarding Python versions?

I think I favor these rules:

• The minimum supported version of Python is set in the requires-python entry in pyproject.toml. This means that pip and other installers will refuse to install the package on older versions of Python.
• The minimum supported version of Python will be tested in CI.
• The minimum supported version of Python will not be changed in a patch release (the z in version number x.y.z).
• The minimum supported version of Python may be changed in a major or minor release (the x and y in x.y.z).
• The minimum supported version of Python will generally follow the minimum supported version of CPython (currently that is 3.9 and about to cycle to 3.10).

These rules should avoid making a change that breaks the package on the older supported version of Python and avoids a newer breaking version from getting installed on an unsupported version of Python.

I think the main question is the last point. Do we keep supporting an old version until someone argues for using a feature that that version does not support or do we just proactively keep raising the minimum version so new features are free to use without that debate? I'd favor just raising the minimum. There are not a lot of new features or bug fixes coming in currently and users of an old version of Python can keep using the last supported version of Uncertainties.

[jagerber48]

All those rules sound great to me. I'm personally comfortable with the "progressive" approach of raising the minimum version when python drop support for a version and then freely using features that break the now unsupported version. Yes, as you say, the recourse for users of unsupported versions of python is that they have to use the oldest version of uncertainties that supports their version of python. The requires-python entry in pyproject.toml helps this work seamlessly.

I'll just say that I'm always eager to use PEP 604 so if we go with this strategy uncertainties will probably break for <3.10 in a few releases. Probably not for 4.0 but maybe sometimes after that. But also, once we drop support (and stop testing) for a version of python I don't want someone saying something like "is it really worth breaking 3.9 just for a small typing feature". Once support is dropped I don't want to have to think about those versions at all. I would rather keep full support (meaning keep tests going) than keep that stuff in the back of my mind.

[newville]

I agree with all of that.

Saying we support "Python 3.10+" starting today is fine with me.

In general, I would be OK with dropping support for the oldest officially supported Python version a few months early, especially if that allows a compelling feature to be used.

[jagerber48]

Saying we support "Python 3.10+" starting today is fine with me.

In general, I would be OK with dropping support for the oldest officially supported Python version a few months early, especially if that allows a compelling feature to be used.

I'm also fine with both of these things.

Just for completeness I'll mention an alternative strategy (which I do not support) for dropping support for a certain python version. The strategy would be to support the lowest version possible until someone wants to use a feature that breaks an old version. Then at that time we discuss if it's worth dropping support for the old python version to allow the feature into the new uncertainties version. As has been pointed out, this approach is more work for the maintainers.

[andrewgsavage]

follow https://numpy.org/neps/nep-0029-deprecation_policy.html

[jagerber48]

Despite the length of the NEP 29 document, the only differences I see between it and wshank's proposal are

• NEP 29 includes testing and support for multiple numpy versions going back 2 years. wshank's proposal doesn't say anything about support old numpy versions, so implicitly that means only supporting the current numpy version given how our current CI works.
• NEP 29 supports python versions for 42 months whereas wshank's proposal is to drop support for a python version when the python steering council (? or whoever) drops official support for that version of python. Right now that event is tied to a 5 year calendar as per PEP 602.

Otherwise I wouldn't say that the NEP 29 makes version control "easier" in any way than wshank's proposal. It's just a decision to test old versions of numpy or not and a question about the specific timeline for dropping support for old versions of python (note the python developer guide has this equivalent page telling you when to drop each version https://devguide.python.org/versions/).

I took a look at pint's CI: https://github.com/hgrecco/pint/blob/master/.github/workflows/ci.yml. It looks like pint does indeed do a 3D scan of OS/python/numpy plus some additional tests looking at other 3rd party packages. We can try out extending uncertainties matrix so we can support uncertainties versions. Assuming the CI is still "cheap", I'm fine to do this.

But for reasons I gave in my last message I would prefer to follow python lifecycle rather then NEP 29. But I'll say that my preference is weak. If others have a stronger opinion I'm happy to defer.

[wshanks]

Uncertainties' API exposure to Python and Numpy seems to be limited enough that compatibility has not been much of an issue. I don't know of any updates needed to account for Python versions 3.6-3.13 and only small changes to the tests for 3.14. For numpy, there were some very small changes (basically just changing some imports) for going from 1 to 2. So I don't mind aiming for a wider compatibility range. It depends on future plans though. We have the refactoring in progress now but beyond that I don't have plans to expand the feature set. If others wanted to do more new development, supporting the older versions could be more of a burden (preventing using newer Python features).

Supporting older numpy versions is an interesting question. Because numpy does not cover the full five year life cycle of Python releases, we get a bit of testing of older numpy versions with our older Python tests. For instance, our Python 3.8 tests are stuck testing numpy 1.24.4 while the 3.13 tests use numpy 2.3.3 now.

So I think the wider window seems okay for this project that has few dependencies and moves at a slower pace. I understand NEP 29's push for a shorter window though for scientific packages generally. Even Python only gives full bugfix support to a release for two years, with the three years after that being only for security fixes.

[wshanks]

I find it makes version support simpler as you don't need to have discussions when you want to drop python/numpy versions as it's predefined.

Yes, this was the main reason I opened the discussion. Whether or not we follow the exact time line of NEP 29, I think having an agreed upon schedule would be better than needing to advocate for when each older version of Python is worth dropping. I don't feel too strongly about the specific dates.

The one other aspect in my original post is when in a release cycle to drop support. In #341, I had just dropped Python 3.8 and 3.9 from the testing and @jagerber48 pushed back on that. Likely the next release will be a patch release. Here I specified that we should drop support in a major or minor release and not in a patch release (like NEP 29 suggests).

Also, looking at the NEP again, I see that it specifies "at least" and seems to be more focused on establishing a common minimum support window than on encouraging the ecosystem to shorten the support window of older Python versions (though it does mention reducing unnecessary support burdens). Still I have seen that many parts of the ecosystem adhere closely to the NEP's minimum window now.

[newville]

I agree with all of that.
Following a 5-year support period for Python versions is completely reasonable. Dropping support for Python versions at 4 years could be acceptable to me if a case is made for that.

NumPy isn't required here, so I don't think there is too much burden that we "must" support 3-year-old NumPy or we're not playing nice with the rest of the "ecosystem".

That is, if there was some reason to require NumPy 2 starting now (and certainly for Version 4), that would be OK with me.

[jagerber48]

The one other aspect in my original post is when in a release cycle to drop support. In #341, I had just dropped Python 3.8 and 3.9 from the testing and @jagerber48 pushed back on that. Likely the next release will be a patch release. Here I specified that we should drop support in a major or minor release and not in a patch release (like NEP 29 suggests).

To be clear I was just pushing back because the original motivation and everything for the PR was related to a minor bug in the edges of our testing but then it felt like changing which versions we support got "snuck in" to that PR. I'm fine to make all the changes at the next release, I just felt, for the record, a dedicated PR was warranted.

yes we've been planning the next release to be 3.2.4, but if we want to include the version support change in the next release I am fine to have it be 3.3.0 instead, skipping 3.2.4 as planned.

It doesn't sound like anyone is strongly in favor of the 42 month python support period so I propose we stick with wshanks original timing: "The minimum supported version of Python will generally follow the minimum supported version of CPython (currently that is 3.9 and about to cycle to 3.10)." Not that 5 years isn't specifically called out, rather our support follows "official" support of CPython. So if the 5 year timeline changes on the CPython side the uncertainties timeline moves with it.

On testing multiple numpy versions: I don't think we need to test against different versions of numpy. In fact, according to NEP 29 support for the last numpy 1.x version ends this coming Tuesday. I think it's probably sufficient to support all major versions of numpy but as of next Tuesday there will only be 1 of these. If we do decide to test multiple numpy versions I don't think we should do a full matrix in the CI. Rather we should just test all versions of numpy together with e.g. the latest or the older version of python on linux.

---

In fewer words: I would vote to adopt exactly what wshanks proposed in the original message in this discussion. Maybe the only edit I would make it explicit that ALL supported versions of python will be tested in CI (the current text only explicitly calls out testing the oldest supported version).

I think adopting this policy solve our immediate short term need. The numpy testing question is less important but happy to continue discussion on it.