Description
Our current versioning policy says:
If a release contains any backwards-incompatible public API changes, the major version number should be incremented (e.g., 2.3.0 -> 3.0.0).
An example of where we could currently have to increment to v4 is at #2819, and @d-v-b also says:
We were already planning on making breaking changes without incrementing the major version number -- deprecated functions like create were slated to be removed long before a 4.x release
So I think the proposal on the table is to update the versioning policy so:
- The major version of
zarr-python
is tied to the Zarr format specification version it supports - The minor version is for breaking changes or major new features
- The micro version is for bugfixes
Ping @zarr-developers/python-core-devs for comment, since this is a major change. Comments/suggestions/disagreements very welcome - if you just generally agree with the above proposal feel free to react with a 👍 to this post.