Deployment policy and SemVer v2-compliant versioning

[Zeitsperre]

Addressing a Problem?

We've run into a problem a few times now with our dependencies, mainly that significantly breaking changes will occur upstream that will force users to manage pins in their environments manually (e.g. the recent time frequency changes in pandas/xarray).

We currently release on a semiregular schedule (every ~5-6 weeks, depending on the urgency/volume of features/fixes). On every push to master, we also bump the development version if internals are changed, but not when only the pyproject.toml changes (which can lead to breaking changes between development versions). In some instances, we need to pin a dependency specifically to prevent the package from breaking, but we don't necessarily have a policy to ensure that this patch fix is made available publicly.

We also use a modified Semantic Versioning (SemVer) system that increases the patch on every significant push to master. The CI system is quite rigorous, so we can be confident that these patch bumps are resilient enough to be released, but seeing as we tend to release on a schedule, these are pre-release version jumps. There's a disconnect there.

Potential Solution

I would like to see xclim adopt a patch release policy to help us determine when we should release a version to fix an outstanding issue affecting the last release (e.g. dependency changes that break the last version).

I can envision simple and complicated ways of managing this:

1. (simple) When code is changed to address a bug in xclim an upstream library, we release the latest development version (dropping -dev); This means we can have patch release jumps in our releases that look like: v0.75.0 → v0.75.6
2. (reasonable, IMO) We move to a system where the patch version is only bumped when we release a patch. This would resemble the pre-release progression convention of SemVer v2, e.g.:
   • v0.1.2 → development bump → v0.1.3-alpha → development bump → v0.1.3-alpha.1
   • v0.22.0 → many development bumps → v0.22.1-alpha.xx → patch release → v0.22.1
3. (complicated) We maintain a stable and a development branch for xclim so that:
   1. Significant bug fixes can be pushed to stable (e.g. v1.2.3 → v.1.2.4-alpha)
   2. stable gets a patch release (e.g. v1.2.4-alpha → v1.2.4)
   3. development can be rebased on stable (v.1.3.0-alpha.xx)

Regardless What we need currently is this:

1. An openly accessible guidance directive on when to make a patch release (can be detailed under CONTRIBUTING.rst)
2. A versioning system that is SemVer-compliant (our current implementation isn't, despite my best efforts)

Additional context

https://semver.org/

"9. A pre-release version MAY be denoted by appending a hyphen and a series of dot separated identifiers immediately following the patch version. Identifiers MUST comprise only ASCII alphanumerics and hyphens [0-9A-Za-z-]. Identifiers MUST NOT be empty. Numeric identifiers MUST NOT include leading zeroes. Pre-release versions have a lower precedence than the associated normal version. A pre-release version indicates that the version is unstable and might not satisfy the intended compatibility requirements, as denoted by its associated normal version. Examples: 1.0.0-alpha, 1.0.0-alpha.1, 1.0.0-0.3.7, 1.0.0-x.7.z.92, 1.0.0-x-y-z.--."

Contribution

• I would be willing/able to open a Pull Request to contribute this feature.

Code of Conduct

• I agree to follow this project's Code of Conduct