Skip to content

Change versioning policy to allow API breaking in minor versions? #2889

Closed
@dstansby

Description

@dstansby

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions