From 4209dafdd7cc56a5c5e1825a4630d74dc4c882ce Mon Sep 17 00:00:00 2001 From: Davis Vann Bennett Date: Fri, 14 Mar 2025 11:57:46 +0100 Subject: [PATCH 01/12] update version policy to use effver --- docs/developers/contributing.rst | 118 ++++++++++++------------------- 1 file changed, 46 insertions(+), 72 deletions(-) diff --git a/docs/developers/contributing.rst b/docs/developers/contributing.rst index de10fab2c6..2d875d3a10 100644 --- a/docs/developers/contributing.rst +++ b/docs/developers/contributing.rst @@ -261,8 +261,8 @@ Merging pull requests ~~~~~~~~~~~~~~~~~~~~~ Pull requests submitted by an external contributor should be reviewed and approved by at least -one core developers before being merged. Ideally, pull requests submitted by a core developer -should be reviewed and approved by at least one other core developers before being merged. +one core developer before being merged. Ideally, pull requests submitted by a core developer +should be reviewed and approved by at least one other core developer before being merged. Pull requests should not be merged until all CI checks have passed (GitHub Actions Codecov) against code that has had the latest main merged in. @@ -270,81 +270,55 @@ Codecov) against code that has had the latest main merged in. Compatibility and versioning policies ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -Because Zarr is a data storage library, there are two types of compatibility to -consider: API compatibility and data format compatibility. - -API compatibility -""""""""""""""""" - -All functions, classes and methods that are included in the API -documentation (files under ``docs/api/*.rst``) are considered as part of the Zarr **public API**, -except if they have been documented as an experimental feature, in which case they are part of -the **experimental API**. - -Any change to the public API that does **not** break existing third party -code importing Zarr, or cause third party code to behave in a different way, is a -**backwards-compatible API change**. For example, adding a new function, class or method is usually -a backwards-compatible change. However, removing a function, class or method; removing an argument -to a function or method; adding a required argument to a function or method; or changing the -behaviour of a function or method, are examples of **backwards-incompatible API changes**. - -If a release contains no changes to the public API (e.g., contains only bug fixes or -other maintenance work), then the micro version number should be incremented (e.g., -2.2.0 -> 2.2.1). If a release contains public API changes, but all changes are -backwards-compatible, then the minor version number should be incremented -(e.g., 2.2.1 -> 2.3.0). 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). - -Backwards-incompatible changes to the experimental API can be included in a minor release, -although this should be minimised if possible. I.e., it would be preferable to save up -backwards-incompatible changes to the experimental API to be included in a major release, and to -stabilise those features at the same time (i.e., move from experimental to public API), rather than -frequently tinkering with the experimental API in minor releases. +Versioning +"""""""""" +The Zarr library uses a version identifier with the form ``..``, where each of value is +an integer. For example, when this document was written the version of Zarr was ``3.0.4``. A release of the Zarr library is associated with a new +version identifier. That new identifier is generated by incrementing exactly one of the components of the previous version identifier by 1. When incrementing the ``major`` +component of the version identifier, the ``minor`` and ``patch`` components are set to 0. + +Releases are classified by the library changes contained in that release. This classification determines which +component of the version identifier is incremented on release. + +* ``major`` releases (for example, ``2.18.0`` -> ``3.0.0``) are for major API changes that will require extensive adaptation efforts from many users and downstream projects. + For example, breaking changes to widely-used user-facing APIs should only be applied in a major release. + + + Users and downstream projects should carefully consider the impact of a major release before adopting it. + In advance of a major release, developers should communicate the scope of the upcoming changes, and help users prepare for them. + +* ``minor`` releases (or example, ``3.0.0`` -> ``3.1.0``) are for minor changes that do not require significant effort from most users or downstream + downstream projects to respond to. API changes are possible in minor releases if the burden on users imposed by those changes is sufficiently small. + For example, a recently released API may need fixes or refinements that are breaking, but low impact + due to the recency of the feature. Such API changes are permitted in a minor release. + + + Minor releases are safe for most users and downstream projects to adopt. + + +* ``patch`` releases (for example, ``3.1.0`` -> ``3.1.1``) are for changes with very low likelihood of + breaking code for a downstream project or user. + + + Users should always feel safe upgrading to a the latest patch release. + +Note that this versioning scheme is not consistent with `Semantic Versioning `_. The Zarr library +may release breaking changes in ``minor`` releases, or even ``patch`` releases under exceptional circumstances. +But we should strive to avoid doing so. A better model for our versioning scheme is `Intended Effort Versioning `_, or "EffVer". +The guiding principle off EffVer is to categorize releases based on the *expected effort required to upgrade to that release*. + Data format compatibility -""""""""""""""""""""""""" - -The data format used by Zarr is defined by a specification document, which should be -platform-independent and contain sufficient detail to construct an interoperable -software library to read and/or write Zarr data using any programming language. The -latest version of the specification document is available on the -`Zarr specifications website `_. - -Here, **data format compatibility** means that all software libraries that implement a -particular version of the Zarr storage specification are interoperable, in the sense -that data written by any one library can be read by all others. It is obviously -desirable to maintain data format compatibility wherever possible. However, if a change -is needed to the storage specification, and that change would break data format -compatibility in any way, then the storage specification version number should be -incremented (e.g., 2 -> 3). - -The versioning of the Zarr software library is related to the versioning of the storage -specification as follows. A particular version of the Zarr library will -implement a particular version of the storage specification. For example, Zarr version -2.2.0 implements the Zarr storage specification version 2. If a release of the Zarr -library implements a different version of the storage specification, then the major -version number of the Zarr library should be incremented. E.g., if Zarr version 2.2.0 -implements the storage spec version 2, and the next release of the Zarr library -implements storage spec version 3, then the next library release should have version -number 3.0.0. Note however that the major version number of the Zarr library may not -always correspond to the spec version number. For example, Zarr versions 2.x, 3.x, and -4.x might all implement the same version of the storage spec and thus maintain data -format compatibility, although they will not maintain API compatibility. - -When to make a release -~~~~~~~~~~~~~~~~~~~~~~ +^^^^^^^^^^^^^^^^^^^^^^^^^ + +The Zarr library is an implementation of a file format standard defined externally -- see the `Zarr specifications website `_ for the list of Zarr file format specifications. -Ideally, any bug fixes that don't change the public API should be released as soon as -possible. It is fine for a micro release to contain only a single bug fix. -When to make a minor release is at the discretion of the core developers. There are no -hard-and-fast rules, e.g., it is fine to make a minor release to make a single new -feature available; equally, it is fine to make a minor release that includes a number of -changes. +If an existing Zarr file format version changes, or a new version of the Zarr file format is released, then the Zarr library will generally require changes. It is very likely that +a new Zarr file format will require extensive breaking changes to the Zarr library, and so support for a new Zarr file format in the Zarr library will almost certainly come in a +major version. For some period of time after the Zarr library adds support for a new Zarr file format, +there may be a period of accelerated changes as developers refine APIs that were added to support the new format. Breaking changes may more frequent until a new API is fully stabilized, and these breaking changes may occur in ``minor`` releases. -Major releases obviously need to be given careful consideration, and should be done as -infrequently as possible, as they will break existing code and/or affect data -compatibility in some way. Release procedure ~~~~~~~~~~~~~~~~~ From f8fc9c1d5f1b83200132f469e52a8bfa555f6104 Mon Sep 17 00:00:00 2001 From: Davis Vann Bennett Date: Fri, 14 Mar 2025 12:02:58 +0100 Subject: [PATCH 02/12] style, fix missing verb --- docs/developers/contributing.rst | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/developers/contributing.rst b/docs/developers/contributing.rst index 2d875d3a10..9b7a247dce 100644 --- a/docs/developers/contributing.rst +++ b/docs/developers/contributing.rst @@ -315,9 +315,9 @@ The Zarr library is an implementation of a file format standard defined external If an existing Zarr file format version changes, or a new version of the Zarr file format is released, then the Zarr library will generally require changes. It is very likely that -a new Zarr file format will require extensive breaking changes to the Zarr library, and so support for a new Zarr file format in the Zarr library will almost certainly come in a -major version. For some period of time after the Zarr library adds support for a new Zarr file format, -there may be a period of accelerated changes as developers refine APIs that were added to support the new format. Breaking changes may more frequent until a new API is fully stabilized, and these breaking changes may occur in ``minor`` releases. +a new Zarr file format will require extensive breaking changes to the Zarr library, and so support for a new Zarr file format in the Zarr library will almost certainly come in new ``major`` release. +For some period of time after the Zarr library adds support for a new Zarr file format, there may be a period of accelerated changes as developers refine APIs that were added to support the new format. +Breaking changes may more frequent until a new API is fully stabilized, and these breaking changes may occur in ``minor`` releases. Release procedure From 26f49274bcff4aa2afaba3e009c78a6d2e0090e0 Mon Sep 17 00:00:00 2001 From: Davis Bennett Date: Fri, 14 Mar 2025 15:51:51 +0100 Subject: [PATCH 03/12] Update docs/developers/contributing.rst Co-authored-by: Joe Hamman --- docs/developers/contributing.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/developers/contributing.rst b/docs/developers/contributing.rst index 9b7a247dce..356e690ad1 100644 --- a/docs/developers/contributing.rst +++ b/docs/developers/contributing.rst @@ -314,7 +314,7 @@ Data format compatibility The Zarr library is an implementation of a file format standard defined externally -- see the `Zarr specifications website `_ for the list of Zarr file format specifications. -If an existing Zarr file format version changes, or a new version of the Zarr file format is released, then the Zarr library will generally require changes. It is very likely that +If an existing Zarr format version changes, or a new version of the Zarr format is released, then the Zarr library will generally require changes. It is very likely that a new Zarr file format will require extensive breaking changes to the Zarr library, and so support for a new Zarr file format in the Zarr library will almost certainly come in new ``major`` release. For some period of time after the Zarr library adds support for a new Zarr file format, there may be a period of accelerated changes as developers refine APIs that were added to support the new format. Breaking changes may more frequent until a new API is fully stabilized, and these breaking changes may occur in ``minor`` releases. From 9dfb39cf796800f1b5e81a2d12c424d51d9e284c Mon Sep 17 00:00:00 2001 From: Davis Bennett Date: Fri, 14 Mar 2025 15:55:25 +0100 Subject: [PATCH 04/12] Update docs/developers/contributing.rst --- docs/developers/contributing.rst | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/docs/developers/contributing.rst b/docs/developers/contributing.rst index 356e690ad1..8c4fc43342 100644 --- a/docs/developers/contributing.rst +++ b/docs/developers/contributing.rst @@ -272,8 +272,7 @@ Compatibility and versioning policies Versioning """""""""" -The Zarr library uses a version identifier with the form ``..``, where each of value is -an integer. For example, when this document was written the version of Zarr was ``3.0.4``. A release of the Zarr library is associated with a new +Versions of this library are identified by a triplet of integers with the form ``..``. For example, when this document was written the version of Zarr was ``3.0.4``. A release of the Zarr library is associated with a new version identifier. That new identifier is generated by incrementing exactly one of the components of the previous version identifier by 1. When incrementing the ``major`` component of the version identifier, the ``minor`` and ``patch`` components are set to 0. From 46f0eb7e0eee5838028df71575d08c62d078d99b Mon Sep 17 00:00:00 2001 From: Davis Bennett Date: Fri, 14 Mar 2025 15:55:56 +0100 Subject: [PATCH 05/12] Update docs/developers/contributing.rst Co-authored-by: Joe Hamman --- docs/developers/contributing.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/developers/contributing.rst b/docs/developers/contributing.rst index 8c4fc43342..20799a23a6 100644 --- a/docs/developers/contributing.rst +++ b/docs/developers/contributing.rst @@ -314,8 +314,8 @@ The Zarr library is an implementation of a file format standard defined external If an existing Zarr format version changes, or a new version of the Zarr format is released, then the Zarr library will generally require changes. It is very likely that -a new Zarr file format will require extensive breaking changes to the Zarr library, and so support for a new Zarr file format in the Zarr library will almost certainly come in new ``major`` release. -For some period of time after the Zarr library adds support for a new Zarr file format, there may be a period of accelerated changes as developers refine APIs that were added to support the new format. +a new Zarr format will require extensive breaking changes to the Zarr library, and so support for a new Zarr format in the Zarr library will almost certainly come in new ``major`` release. +For some period of time after the Zarr library adds support for a new Zarr format, there may be a period of accelerated changes as developers refine APIs that were added to support the new format. Breaking changes may more frequent until a new API is fully stabilized, and these breaking changes may occur in ``minor`` releases. From 668be29176609850f7f4d392a50ed2edabef3221 Mon Sep 17 00:00:00 2001 From: Davis Bennett Date: Fri, 14 Mar 2025 16:48:40 +0100 Subject: [PATCH 06/12] Update docs/developers/contributing.rst Co-authored-by: David Stansby --- docs/developers/contributing.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/developers/contributing.rst b/docs/developers/contributing.rst index 20799a23a6..167bd7e4d9 100644 --- a/docs/developers/contributing.rst +++ b/docs/developers/contributing.rst @@ -272,7 +272,7 @@ Compatibility and versioning policies Versioning """""""""" -Versions of this library are identified by a triplet of integers with the form ``..``. For example, when this document was written the version of Zarr was ``3.0.4``. A release of the Zarr library is associated with a new +Versions of this library are identified by a triplet of integers with the form ``..``, for example 3.0.4. A release of ``zarr-python`` is associated with a new version identifier. That new identifier is generated by incrementing exactly one of the components of the previous version identifier by 1. When incrementing the ``major`` component of the version identifier, the ``minor`` and ``patch`` components are set to 0. From f25d84ced91f99b0803ac1e8748522b13dc79c0d Mon Sep 17 00:00:00 2001 From: Davis Bennett Date: Fri, 14 Mar 2025 16:49:05 +0100 Subject: [PATCH 07/12] Update docs/developers/contributing.rst Co-authored-by: David Stansby --- docs/developers/contributing.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/developers/contributing.rst b/docs/developers/contributing.rst index 167bd7e4d9..632ef5b26c 100644 --- a/docs/developers/contributing.rst +++ b/docs/developers/contributing.rst @@ -274,7 +274,7 @@ Versioning """""""""" Versions of this library are identified by a triplet of integers with the form ``..``, for example 3.0.4. A release of ``zarr-python`` is associated with a new version identifier. That new identifier is generated by incrementing exactly one of the components of the previous version identifier by 1. When incrementing the ``major`` -component of the version identifier, the ``minor`` and ``patch`` components are set to 0. +component of the version identifier, the ``minor`` and ``patch`` components is reset to 0. When incrementing the minor component, the patch component is reset to 0. Releases are classified by the library changes contained in that release. This classification determines which component of the version identifier is incremented on release. From a0ae8105d7464b78c6149cac94ecfac61d8c0e40 Mon Sep 17 00:00:00 2001 From: Davis Bennett Date: Fri, 14 Mar 2025 16:49:45 +0100 Subject: [PATCH 08/12] Update docs/developers/contributing.rst Co-authored-by: David Stansby --- docs/developers/contributing.rst | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/docs/developers/contributing.rst b/docs/developers/contributing.rst index 632ef5b26c..1fcd33b93a 100644 --- a/docs/developers/contributing.rst +++ b/docs/developers/contributing.rst @@ -295,8 +295,7 @@ component of the version identifier is incremented on release. Minor releases are safe for most users and downstream projects to adopt. -* ``patch`` releases (for example, ``3.1.0`` -> ``3.1.1``) are for changes with very low likelihood of - breaking code for a downstream project or user. +* ``patch`` releases (for example, ``3.1.0`` -> ``3.1.1``) are for changes that contain no breaking or behaviour changes for downstream projects or users. Examples of changes in a patch release are bugfixes and documentation improvements. Users should always feel safe upgrading to a the latest patch release. From b90f0ef358d3dded5b7462e8594ef4dccfd41dc1 Mon Sep 17 00:00:00 2001 From: Davis Vann Bennett Date: Mon, 17 Mar 2025 12:10:08 +0100 Subject: [PATCH 09/12] add language about keeping changes smooth --- docs/developers/contributing.rst | 2 ++ 1 file changed, 2 insertions(+) diff --git a/docs/developers/contributing.rst b/docs/developers/contributing.rst index 1fcd33b93a..22a05d53d4 100644 --- a/docs/developers/contributing.rst +++ b/docs/developers/contributing.rst @@ -305,6 +305,8 @@ may release breaking changes in ``minor`` releases, or even ``patch`` releases u But we should strive to avoid doing so. A better model for our versioning scheme is `Intended Effort Versioning `_, or "EffVer". The guiding principle off EffVer is to categorize releases based on the *expected effort required to upgrade to that release*. +Zarr developers should make changes as smooth as possible for users. This means making backwards-compatible changes wherever possible. +When a backwards-incompatible change is necessary, users should be notified well in advance, e.g. via informative deprecation warnings. Data format compatibility ^^^^^^^^^^^^^^^^^^^^^^^^^ From ac7ac72c3e26d8ff72d2f17ac54133b7e31b714a Mon Sep 17 00:00:00 2001 From: Davis Bennett Date: Tue, 18 Mar 2025 13:00:49 +0100 Subject: [PATCH 10/12] Update docs/developers/contributing.rst --- docs/developers/contributing.rst | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/docs/developers/contributing.rst b/docs/developers/contributing.rst index 22a05d53d4..08f1258ab5 100644 --- a/docs/developers/contributing.rst +++ b/docs/developers/contributing.rst @@ -316,8 +316,7 @@ The Zarr library is an implementation of a file format standard defined external If an existing Zarr format version changes, or a new version of the Zarr format is released, then the Zarr library will generally require changes. It is very likely that a new Zarr format will require extensive breaking changes to the Zarr library, and so support for a new Zarr format in the Zarr library will almost certainly come in new ``major`` release. -For some period of time after the Zarr library adds support for a new Zarr format, there may be a period of accelerated changes as developers refine APIs that were added to support the new format. -Breaking changes may more frequent until a new API is fully stabilized, and these breaking changes may occur in ``minor`` releases. +When the Zarr library adds support for a new Zarr format, there may be a period of accelerated changes as developers refine newly added APIs and deprecate old APIs. In such a transitional phase breaking changes may be more frequent than usual. Release procedure From 58effb9d7a6e31fd4c14a8173d8a47a880d77946 Mon Sep 17 00:00:00 2001 From: Davis Vann Bennett Date: Fri, 21 Mar 2025 14:03:44 +0100 Subject: [PATCH 11/12] linewrap and style --- docs/developers/contributing.rst | 70 +++++++++++++++++++++----------- 1 file changed, 46 insertions(+), 24 deletions(-) diff --git a/docs/developers/contributing.rst b/docs/developers/contributing.rst index 08f1258ab5..fa65f71d48 100644 --- a/docs/developers/contributing.rst +++ b/docs/developers/contributing.rst @@ -272,22 +272,30 @@ Compatibility and versioning policies Versioning """""""""" -Versions of this library are identified by a triplet of integers with the form ``..``, for example 3.0.4. A release of ``zarr-python`` is associated with a new -version identifier. That new identifier is generated by incrementing exactly one of the components of the previous version identifier by 1. When incrementing the ``major`` -component of the version identifier, the ``minor`` and ``patch`` components is reset to 0. When incrementing the minor component, the patch component is reset to 0. - -Releases are classified by the library changes contained in that release. This classification determines which -component of the version identifier is incremented on release. - -* ``major`` releases (for example, ``2.18.0`` -> ``3.0.0``) are for major API changes that will require extensive adaptation efforts from many users and downstream projects. +Versions of this library are identified by a triplet of integers with the form +``..``, for example ``3.0.4``. A release of ``zarr-python`` is associated with a new +version identifier. That new identifier is generated by incrementing exactly one of the components of +the previous version identifier by 1. When incrementing the ``major`` component of the version identifier, +the ``minor`` and ``patch`` components is reset to 0. When incrementing the minor component, +the patch component is reset to 0. + +Releases are classified by the library changes contained in that release. This classification +determines which component of the version identifier is incremented on release. + +* ``major`` releases (for example, ``2.18.0`` -> ``3.0.0``) are for changes that will + require extensive adaptation efforts from many users and downstream projects. For example, breaking changes to widely-used user-facing APIs should only be applied in a major release. - Users and downstream projects should carefully consider the impact of a major release before adopting it. - In advance of a major release, developers should communicate the scope of the upcoming changes, and help users prepare for them. + Users and downstream projects should carefully consider the impact of a major release before + adopting it. + In advance of a major release, developers should communicate the scope of the upcoming changes, + and help users prepare for them. + +* ``minor`` releases (or example, ``3.0.0`` -> ``3.1.0``) are for changes that do not require + significant effort from most users or downstream downstream projects to respond to. API changes + are possible in minor releases if the burden on users imposed by those changes is sufficiently small. -* ``minor`` releases (or example, ``3.0.0`` -> ``3.1.0``) are for minor changes that do not require significant effort from most users or downstream - downstream projects to respond to. API changes are possible in minor releases if the burden on users imposed by those changes is sufficiently small. For example, a recently released API may need fixes or refinements that are breaking, but low impact due to the recency of the feature. Such API changes are permitted in a minor release. @@ -295,28 +303,40 @@ component of the version identifier is incremented on release. Minor releases are safe for most users and downstream projects to adopt. -* ``patch`` releases (for example, ``3.1.0`` -> ``3.1.1``) are for changes that contain no breaking or behaviour changes for downstream projects or users. Examples of changes in a patch release are bugfixes and documentation improvements. +* ``patch`` releases (for example, ``3.1.0`` -> ``3.1.1``) are for changes that contain no breaking + or behaviour changes for downstream projects or users. Examples of changes suitable for a patch release are + bugfixes and documentation improvements. Users should always feel safe upgrading to a the latest patch release. -Note that this versioning scheme is not consistent with `Semantic Versioning `_. The Zarr library -may release breaking changes in ``minor`` releases, or even ``patch`` releases under exceptional circumstances. -But we should strive to avoid doing so. A better model for our versioning scheme is `Intended Effort Versioning `_, or "EffVer". -The guiding principle off EffVer is to categorize releases based on the *expected effort required to upgrade to that release*. +Note that this versioning scheme is not consistent with `Semantic Versioning `_. +Contrary to SemVer, the Zarr library may release breaking changes in ``minor`` releases, or even +``patch`` releases under exceptional circumstances. But we should strive to avoid doing so. + +A better model for our versioning scheme is `Intended Effort Versioning `_, +or "EffVer". The guiding principle off EffVer is to categorize releases based on the *expected effort +required to upgrade to that release*. -Zarr developers should make changes as smooth as possible for users. This means making backwards-compatible changes wherever possible. -When a backwards-incompatible change is necessary, users should be notified well in advance, e.g. via informative deprecation warnings. +Zarr developers should make changes as smooth as possible for users. This means making +backwards-compatible changes wherever possible. When a backwards-incompatible change is necessary, +users should be notified well in advance, e.g. via informative deprecation warnings. Data format compatibility ^^^^^^^^^^^^^^^^^^^^^^^^^ -The Zarr library is an implementation of a file format standard defined externally -- see the `Zarr specifications website `_ for the list of Zarr file format specifications. +The Zarr library is an implementation of a file format standard defined externally -- +see the `Zarr specifications website `_ for the list of +Zarr file format specifications. -If an existing Zarr format version changes, or a new version of the Zarr format is released, then the Zarr library will generally require changes. It is very likely that -a new Zarr format will require extensive breaking changes to the Zarr library, and so support for a new Zarr format in the Zarr library will almost certainly come in new ``major`` release. -When the Zarr library adds support for a new Zarr format, there may be a period of accelerated changes as developers refine newly added APIs and deprecate old APIs. In such a transitional phase breaking changes may be more frequent than usual. +If an existing Zarr format version changes, or a new version of the Zarr format is released, then +the Zarr library will generally require changes. It is very likely that a new Zarr format will +require extensive breaking changes to the Zarr library, and so support for a new Zarr format in the +Zarr library will almost certainly come in new ``major`` release. +When the Zarr library adds support for a new Zarr format, there may be a period of accelerated +changes as developers refine newly added APIs and deprecate old APIs. In such a transitional phase +breaking changes may be more frequent than usual. Release procedure @@ -360,5 +380,7 @@ pre-releases will be available under Post-release """""""""""" -- Review and merge the pull request on the `conda-forge feedstock `_ that will be automatically generated. +- Review and merge the pull request on the + `conda-forge feedstock `_ that will be + automatically generated. - Create a new "Unreleased" section in the release notes From 685342c966f9ebf69abceb755b93ab5dd0f4a427 Mon Sep 17 00:00:00 2001 From: Davis Vann Bennett Date: Fri, 21 Mar 2025 14:11:50 +0100 Subject: [PATCH 12/12] chore: release notes --- changes/2924.chore.rst | 2 ++ 1 file changed, 2 insertions(+) create mode 100644 changes/2924.chore.rst diff --git a/changes/2924.chore.rst b/changes/2924.chore.rst new file mode 100644 index 0000000000..7bfbb2e1c7 --- /dev/null +++ b/changes/2924.chore.rst @@ -0,0 +1,2 @@ +Define a new versioning policy based on Effective Effort Versioning. This replaces the old +Semantic Versioning-based policy. \ No newline at end of file