Skip to content
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

switch to CalVer? #179

Open
keewis opened this issue Jul 27, 2022 · 0 comments
Open

switch to CalVer? #179

keewis opened this issue Jul 27, 2022 · 0 comments

Comments

@keewis
Copy link
Collaborator

keewis commented Jul 27, 2022

Our release policy very much follows that of xarray: deprecations will stay in a few releases, after which they will be applied (for example, removing old features or changing defaults).

This makes it somewhat difficult to choose the new version (when do we bump the which part of the version), and in my experience is often done somewhat arbitrarily. In addition, the version scheme is often confused with SemVer, which is not what we're doing.

With CalVer this is very easy: the version is always YYYY.0M.X, and if there's multiple releases per month we just have to increase X (for example, if there were bugs in the release).

As such, I would like to propose following xarray and switching to CalVer. What do you think?

@keewis keewis changed the title switching to CalVer switch to CalVer? Jul 27, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant