version 1.4.0

[iainrussell]

Checklist

• [x] Used a personal fork of the feedstock to propose changes
• [ ] Bumped the build number (if the version is unchanged)
• [x] Reset the build number to 0 (if the version changed)
• [ ] Re-rendered with the latest conda-smithy (Use the phrase code>@<space/conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
• [ ] Ensured the license file is being packaged.

This is part of a larger piece of work to remove all the badly tagged versions (e.g. 2021.05.0) and replace them with the 'proper' versions, e.g. 1.4.0. I will try to create a 1.4.0 version and mark all the others on anaconda as broken. Existing users will still have the problem that if they have a version 2021.* installed then most likely their conda systems will not see the new versions as being newer and will not update to them. But since we no longer push the 'date-like' tags, no newer versions will become available to them anyway (we now only push the 'proper' tags). At least this way we have proper versioning and conda-forge should detect new versions when they are released.

[conda-forge-linter]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

I do have some suggestions for making it better though...

For recipe:

• License is not an SPDX identifier (or a custom LicenseRef) nor an SPDX license expression.

Documentation on acceptable licenses can be found here.

[jamesp]

Hi @iainrussell the change marking all other versions as "broken" associated with this PR is causing us a bit of bother. We have a fair number of conda environments for legacy code that use old versions of python-eccodes. This was no problem as they could be pinned to the appropriate version in the environment.yml.

Since this change none of these environments can be reproduced as conda can't find any of the old versions in the repodata.

Is there any alternative to eliminating all these old versions from the conda-forge history?

[iainrussell]

Hi @jamesp , not as far as I know. It might be possible to re-release those versions with their proper version numbers, and give you a mapping, e.g. 2021.06.0 -> 0.9.8 or whatever, but I could imagine there might be problems with that, as we would be releasing older versions with the new conda machinery. But if that sounds useful to you, we could try it for one version to start with (tell me which one) and once it's built, you can substitute the proper version number into your environment. If that works we can look at the others.

[jamesp]

Thanks for the suggestion @iainrussell. I understand why you've made the change, this seems an unfortunate consequence of no good way of handling a non-monotonic change in version number in conda.

I expect it will be impractical use of your and my time to map the versions. It might solve my particular problem but not a general fix. There are a lot of codebases out there who would not know about the remap and don't have the developers around any more to support making the required changes and tests. Unless you hear from a lot of other users with similar issues.