Version pinning for main #580
Conversation
… to allow more flexibility for users
The previous code worked on local testing but failed in the pipeline
|
|
Ah that's an oversight, thanks. Should be >= 3.9, I'll fix it now |
There was a problem hiding this comment.
I'm okay to approve this as is for a first pass.
I do however, have some uncertainties - but these may be addressed later if any usability issues arise:
I'm a bit unsure of how to handle xarray, since an increment in calendar year, does not necessarily mean a major version bump that would break compatibility.
I can think of situations e.g. beginning of 2025, where we may want to include both 2024 and 2025.
For now this may be fine but my optional recommendation is to include a compatiblity version (~=) for numpy and use >= for xarray. I believe xarray has a hard dependency on numpy, so it should auto-resolve to the appropriate xarray version that is above the minimum required.
|
For the versions coming soon, I think 2024 is okay for xarray. As we approach 2025, perhaps we include both in those releases, it's a valid point but I think we can handle it when we get there. |
|
Okay, thanks everyone for their comments. I'm going to merge this in now. I'll make sure CI is happy (it should be) and will do some manual testing of things as we approach version 1 to see that things are behaving well. |
This PR sets some pinned versions for the main branch, which are not included in develop. The intention would be to include these pinned versions in the tagged releases, but allow develop to update freely.
The versions specified are:
~= is an "approximate" match, meaning >= the specified version, but not going above the major version. This should mean that tagged releases are protected against breaking API changes which may be introduced by major upgrades in dependencies.
It is generally accepted best practise to specify version ranges which are supported by particular releases. We could potentially seek to support a very wide range of versions, or focus only on the versions which have been recently tested. I could not find any prescriptive or definitive guidance on how to select versions for dependencies.
I hope these versions mean that people who have to use older versions of things could still integrate scores, while those wanting to keep up-to-date can easily do so. Over time, if we get many user requests for supporting older package versions, we could expand the range of acceptable versions accordingly.
Currently, all the pinned versions are somewhat (around 6 months) behind those brought in during automated testing for Python 3.9. So an "up to date" 3.9 installation is supported, but an "out of date" 3.9 installation is not, but potentially could be.
At this stage, our project doesn't have the resources to manually support more complexity than this, and it seems a reasonable place to start.
Fixes #517