-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Come up with a python version support policy and implement in CI #49
Comments
What's happened here is the We've been keeping Python3.7 support as currently it is still DLS's reference python3 version. Once we can get rid of that we could look at dropping 3.7 support. |
Ok, even if we can't drop support for it can we include up to 3.12 on the CI as downstream applications are using it? |
This is a stable module with few changes, so I suggest that we follow the approach of "we guarantee to support NEP29, but will keep old versions of python if it doesn't cause us any pain". Basically as soon as GitHub/numpy/epicscorelibs makes it difficult to support an old python we drop it, but we make sure that we add new pythons inline with the copier template. |
As of the new 1.8 release, there is now a published version with support up to Python 3.11. |
Currently the python 3.7 tests are failing, it looks like potentially because there is no longer an installable version of 3.7 for that OS (https://github.com/DiamondLightSource/aioca/actions/runs/9990760182/job/27612112943). Either way 3.7 is very old now so we should think about when to drop it.
We should write a page in the aioca documentation on what our depreciation policy is then make CI match it. For other DLS projects we follow https://numpy.org/neps/nep-0029-deprecation_policy.html, if we followed that the CI should be updated to run against 3.10+
The text was updated successfully, but these errors were encountered: