From 5dc80aaf04b41f2d2ad2ff94386afdfcc4c5320e Mon Sep 17 00:00:00 2001 From: Davis Vann Bennett Date: Thu, 20 Mar 2025 13:03:04 +0100 Subject: [PATCH 01/11] add version policy change post --- .../2025-03-20-switching-to-effver.markdown | 42 +++++++++++++++++++ 1 file changed, 42 insertions(+) create mode 100644 _posts/2025-03-20-switching-to-effver.markdown diff --git a/_posts/2025-03-20-switching-to-effver.markdown b/_posts/2025-03-20-switching-to-effver.markdown new file mode 100644 index 0000000..ebddd8f --- /dev/null +++ b/_posts/2025-03-20-switching-to-effver.markdown @@ -0,0 +1,42 @@ +--- +layout: post +title: 'Versioning Zarr with EffVer' +description: We are updating the versioning policy for the Zarr python library. +date: 2025-01-09 +categories: blog +permalink: /versioning-with-effver/ +--- + +Back in January we released [Zarr-Python 3](https://zarr.readthedocs.io/en/v3.0.0/), the first new version of the library since 2016. While working on this release, we found that Zarr-Python's versioning policy didn't quite fit the needs of the project as it stands today. So we are modifying that versioning policy to make it better suited to the needs of Zarr-Python developers and users. + +This post will explain what our old versioning policy was, why it wasn't working well for us, and why we are switching to ["Intended Effort Versioning"](https://jacobtomlinson.dev/effver/), or "EffVer". + +### Our old versioning policy + +The old Zarr-Python versioning policy was effectively [Semantic Versioning](https://semver.org/), or "SemVer". In this scheme, backwards-incompatible API changes may only be released in major versions, backwards-compatible API changes (i.e., adding new APIs) may only be released in minor or major versions, and bug fixes can be released in major, minor, or patch versions. + +But in practice, we found that adherence to SemVer was a source of friction. The impetus for releasing Zarr-Python 3 was to support a new version of the Zarr format. So Zarr-Python 3 was released with a lot of new APIs; some of these APIs have bugs or warts. + +For example, we released some functions that should have consistent default values, but due to this author's error, they don't (I choose to blame the lack of tests!). [The fix](https://github.com/zarr-developers/zarr-python/pull/2819) is simple, in terms of code changes, but it requires breaking changes to our public API. Thus our old versioning policy would require that we ship these fixes in Zarr-Python 4, only a few months after we released 3. + +Our users assume that major releases Zarr-Python will contain sweeping changes, not tiny adjustments to public APIs. So releasing version 4 of Zarr-Python because we changed the default values of a few functions would likely confuse people. + +We learned that SemVer does not actually fit our project very well, so we decided to update the versioning policy accordingly. If you are interested in the developer discussion about this topic, see this [Github issue](https://github.com/zarr-developers/zarr-python/issues/2889). + +### Our new versioning policy + +We were accustomed to thinking about major releases of Zarr-Python as epochal events that would offer lots of new functionality to users, but also require substantial changes to existing code. [Jacob Tomlinson](https://jacobtomlinson.dev/) extended this framing to a full versioning scheme, which he calls (https://jacobtomlinson.dev/effver/), or "EffVer" for short. + +The basic idea of EffVer is that you version your project according to the expected effort a user will spend in upgrading to that version. + +- Major releases should contain changes have the most impact on users, and thus require the most effort to adopt. +- Minor releases can require some effort from some users. +- Patch releases should require no effort from users. + +SemVer indexes changes on whether they are backwards compatible or not. By contrast, EffVer indexes changes on how much effort is required for users to adapt to them. Thus EffVer allows us to ship small-but-breaking changes -- like changing default values of some recently-added functions -- in a minor release, as long as we don't think adapting to these changes will require substantial effort from users. + +### Conclusion + +We think switching to EffVer is right for Zarr-Python development. It lets us refine newly-added APIs while reserving major releases for epochal changes, like the Zarr-Python 2 -> 3 transition. + +If you have any thoughts or concerns about this decision, we would love to hear from you. The best way to reach us is to open an [issue](https://github.com/zarr-developers/zarr-python/issues) or [discussion](https://github.com/zarr-developers/zarr-python/discussions) on our [Github page](https://github.com/zarr-developers/zarr-python). Thanks for your time! From f37ea0aa92127b37f7d2fda39a2c30cf3c543a7b Mon Sep 17 00:00:00 2001 From: Davis Vann Bennett Date: Thu, 20 Mar 2025 13:15:03 +0100 Subject: [PATCH 02/11] add subsection about friction --- _posts/2025-03-20-switching-to-effver.markdown | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/_posts/2025-03-20-switching-to-effver.markdown b/_posts/2025-03-20-switching-to-effver.markdown index ebddd8f..5127339 100644 --- a/_posts/2025-03-20-switching-to-effver.markdown +++ b/_posts/2025-03-20-switching-to-effver.markdown @@ -15,9 +15,13 @@ This post will explain what our old versioning policy was, why it wasn't working The old Zarr-Python versioning policy was effectively [Semantic Versioning](https://semver.org/), or "SemVer". In this scheme, backwards-incompatible API changes may only be released in major versions, backwards-compatible API changes (i.e., adding new APIs) may only be released in minor or major versions, and bug fixes can be released in major, minor, or patch versions. -But in practice, we found that adherence to SemVer was a source of friction. The impetus for releasing Zarr-Python 3 was to support a new version of the Zarr format. So Zarr-Python 3 was released with a lot of new APIs; some of these APIs have bugs or warts. +#### Friction with SemVer -For example, we released some functions that should have consistent default values, but due to this author's error, they don't (I choose to blame the lack of tests!). [The fix](https://github.com/zarr-developers/zarr-python/pull/2819) is simple, in terms of code changes, but it requires breaking changes to our public API. Thus our old versioning policy would require that we ship these fixes in Zarr-Python 4, only a few months after we released 3. +The impetus for releasing Zarr-Python 3 was to support a new version of the Zarr format. So Zarr-Python 3 was released with a lot of new APIs; some of these APIs have bugs or warts. + +For example, we released some functions that *should* have consistent default values, but due to developer error (this author's error, in fact) those functions are inconsistent. [The fix](https://github.com/zarr-developers/zarr-python/pull/2819) is simple, in terms of code changes, but it requires breaking changes to our public API. According to SemVer, fixing this would require releasing Zarr-Python 4, only a few months after we released 3. + +Besides fixing bugs in new APIs, we released Zarr-Python 3 with deprecation notices for many old APIs. We would like to eventually remove these routines from Zarr-Python, but we don't think it would match our user's expectations if we released a new major version of the library just to signify removing code. Again, this is contrary to SemVer. Our users assume that major releases Zarr-Python will contain sweeping changes, not tiny adjustments to public APIs. So releasing version 4 of Zarr-Python because we changed the default values of a few functions would likely confuse people. From d1f501dc925b3d21bb9012d19764bf67f761689a Mon Sep 17 00:00:00 2001 From: Davis Bennett Date: Thu, 20 Mar 2025 23:16:04 +0100 Subject: [PATCH 03/11] Update _posts/2025-03-20-switching-to-effver.markdown --- _posts/2025-03-20-switching-to-effver.markdown | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_posts/2025-03-20-switching-to-effver.markdown b/_posts/2025-03-20-switching-to-effver.markdown index 5127339..5fd6bff 100644 --- a/_posts/2025-03-20-switching-to-effver.markdown +++ b/_posts/2025-03-20-switching-to-effver.markdown @@ -21,7 +21,7 @@ The impetus for releasing Zarr-Python 3 was to support a new version of the Zarr For example, we released some functions that *should* have consistent default values, but due to developer error (this author's error, in fact) those functions are inconsistent. [The fix](https://github.com/zarr-developers/zarr-python/pull/2819) is simple, in terms of code changes, but it requires breaking changes to our public API. According to SemVer, fixing this would require releasing Zarr-Python 4, only a few months after we released 3. -Besides fixing bugs in new APIs, we released Zarr-Python 3 with deprecation notices for many old APIs. We would like to eventually remove these routines from Zarr-Python, but we don't think it would match our user's expectations if we released a new major version of the library just to signify removing code. Again, this is contrary to SemVer. +Besides fixing bugs in new APIs, we released Zarr-Python 3 with deprecation notices for many old APIs. We would like to eventually remove these routines from Zarr-Python, but we don't think it would match user expectations if we released a new major version of the library just to signify removing code. Again, this is contrary to SemVer. Our users assume that major releases Zarr-Python will contain sweeping changes, not tiny adjustments to public APIs. So releasing version 4 of Zarr-Python because we changed the default values of a few functions would likely confuse people. From 97e1ef36fa2335c26d660baf9921abebffa8dafd Mon Sep 17 00:00:00 2001 From: Josh Moore Date: Fri, 28 Mar 2025 12:22:58 +0100 Subject: [PATCH 04/11] Apply suggestions from code review Co-authored-by: Sanket Verma --- _posts/2025-03-20-switching-to-effver.markdown | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_posts/2025-03-20-switching-to-effver.markdown b/_posts/2025-03-20-switching-to-effver.markdown index 5fd6bff..9ac85e2 100644 --- a/_posts/2025-03-20-switching-to-effver.markdown +++ b/_posts/2025-03-20-switching-to-effver.markdown @@ -29,7 +29,7 @@ We learned that SemVer does not actually fit our project very well, so we decide ### Our new versioning policy -We were accustomed to thinking about major releases of Zarr-Python as epochal events that would offer lots of new functionality to users, but also require substantial changes to existing code. [Jacob Tomlinson](https://jacobtomlinson.dev/) extended this framing to a full versioning scheme, which he calls (https://jacobtomlinson.dev/effver/), or "EffVer" for short. +We were accustomed to thinking about major releases of Zarr-Python as epochal events that would offer lots of new functionality to users, but also require substantial changes to existing code. [Jacob Tomlinson](https://jacobtomlinson.dev/) extended this framing to a full versioning scheme, which he calls (), or "EffVer" for short. The basic idea of EffVer is that you version your project according to the expected effort a user will spend in upgrading to that version. From 34b1d0639dd3a246e46a5fbf20f13d7dddb3de90 Mon Sep 17 00:00:00 2001 From: Davis Vann Bennett Date: Fri, 28 Mar 2025 12:27:21 +0100 Subject: [PATCH 05/11] fix hyperlink --- _posts/2025-03-20-switching-to-effver.markdown | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_posts/2025-03-20-switching-to-effver.markdown b/_posts/2025-03-20-switching-to-effver.markdown index 9ac85e2..c952786 100644 --- a/_posts/2025-03-20-switching-to-effver.markdown +++ b/_posts/2025-03-20-switching-to-effver.markdown @@ -29,7 +29,7 @@ We learned that SemVer does not actually fit our project very well, so we decide ### Our new versioning policy -We were accustomed to thinking about major releases of Zarr-Python as epochal events that would offer lots of new functionality to users, but also require substantial changes to existing code. [Jacob Tomlinson](https://jacobtomlinson.dev/) extended this framing to a full versioning scheme, which he calls (), or "EffVer" for short. +We were accustomed to thinking about major releases of Zarr-Python as epochal events that would offer lots of new functionality to users, but also require substantial changes to existing code. [Jacob Tomlinson](https://jacobtomlinson.dev/) extended this framing to a full versioning scheme, which he calls [Intended Effort Versioning](https://jacobtomlinson.dev/effver/), or "EffVer" for short. The basic idea of EffVer is that you version your project according to the expected effort a user will spend in upgrading to that version. From 40bb0f701e1e0bd7965964bd9664a2651c2f276c Mon Sep 17 00:00:00 2001 From: Davis Vann Bennett Date: Fri, 28 Mar 2025 12:33:28 +0100 Subject: [PATCH 06/11] prose --- _posts/2025-03-20-switching-to-effver.markdown | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/_posts/2025-03-20-switching-to-effver.markdown b/_posts/2025-03-20-switching-to-effver.markdown index c952786..e4a6f0b 100644 --- a/_posts/2025-03-20-switching-to-effver.markdown +++ b/_posts/2025-03-20-switching-to-effver.markdown @@ -29,15 +29,17 @@ We learned that SemVer does not actually fit our project very well, so we decide ### Our new versioning policy -We were accustomed to thinking about major releases of Zarr-Python as epochal events that would offer lots of new functionality to users, but also require substantial changes to existing code. [Jacob Tomlinson](https://jacobtomlinson.dev/) extended this framing to a full versioning scheme, which he calls [Intended Effort Versioning](https://jacobtomlinson.dev/effver/), or "EffVer" for short. +We were accustomed to thinking about major releases of Zarr-Python as epochal events that offer lots of new functionality to users (like a brand new version of the underlying Zarr format), but also require substantial changes to existing code. In other words, while major releases likely contain backwards-incompatible changes, backwards-incompatible changes on their own don't really warrany a major release. + +[Jacob Tomlinson](https://jacobtomlinson.dev/) extended this framing to a full versioning scheme, which he calls [Intended Effort Versioning](https://jacobtomlinson.dev/effver/), or "EffVer" for short. The basic idea of EffVer is that you version your project according to the expected effort a user will spend in upgrading to that version. - Major releases should contain changes have the most impact on users, and thus require the most effort to adopt. -- Minor releases can require some effort from some users. -- Patch releases should require no effort from users. +- Minor releases can require some adoption effort from some users. +- Patch releases should require no adoption effort from users. -SemVer indexes changes on whether they are backwards compatible or not. By contrast, EffVer indexes changes on how much effort is required for users to adapt to them. Thus EffVer allows us to ship small-but-breaking changes -- like changing default values of some recently-added functions -- in a minor release, as long as we don't think adapting to these changes will require substantial effort from users. +While SemVer indexes code changes by whether they are backwards compatible or not, EffVer indexes changes on how much effort is required for users to adapt to them. Thus EffVer allows us to ship small-but-breaking changes -- like changing default values of some recently-added functions -- in a minor release, so long as we think these changes will be easy for users to integrate. ### Conclusion From 1bdcb4da2bba7dd3842af655db500fa1ba61221d Mon Sep 17 00:00:00 2001 From: Davis Vann Bennett Date: Fri, 28 Mar 2025 12:33:51 +0100 Subject: [PATCH 07/11] prose --- _posts/2025-03-20-switching-to-effver.markdown | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/_posts/2025-03-20-switching-to-effver.markdown b/_posts/2025-03-20-switching-to-effver.markdown index e4a6f0b..5e7c672 100644 --- a/_posts/2025-03-20-switching-to-effver.markdown +++ b/_posts/2025-03-20-switching-to-effver.markdown @@ -31,9 +31,7 @@ We learned that SemVer does not actually fit our project very well, so we decide We were accustomed to thinking about major releases of Zarr-Python as epochal events that offer lots of new functionality to users (like a brand new version of the underlying Zarr format), but also require substantial changes to existing code. In other words, while major releases likely contain backwards-incompatible changes, backwards-incompatible changes on their own don't really warrany a major release. -[Jacob Tomlinson](https://jacobtomlinson.dev/) extended this framing to a full versioning scheme, which he calls [Intended Effort Versioning](https://jacobtomlinson.dev/effver/), or "EffVer" for short. - -The basic idea of EffVer is that you version your project according to the expected effort a user will spend in upgrading to that version. +[Jacob Tomlinson](https://jacobtomlinson.dev/) extended this framing to a full versioning scheme, which he calls [Intended Effort Versioning](https://jacobtomlinson.dev/effver/), or "EffVer" for short. The basic idea of EffVer is that you version your project according to the expected effort a user will spend in upgrading to that version. - Major releases should contain changes have the most impact on users, and thus require the most effort to adopt. - Minor releases can require some adoption effort from some users. From 16a6aba6bcc8be1f3ec7904f7f6328d6a3e8a550 Mon Sep 17 00:00:00 2001 From: Davis Vann Bennett Date: Fri, 28 Mar 2025 12:34:59 +0100 Subject: [PATCH 08/11] typo --- _posts/2025-03-20-switching-to-effver.markdown | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_posts/2025-03-20-switching-to-effver.markdown b/_posts/2025-03-20-switching-to-effver.markdown index 5e7c672..df6e8d3 100644 --- a/_posts/2025-03-20-switching-to-effver.markdown +++ b/_posts/2025-03-20-switching-to-effver.markdown @@ -29,7 +29,7 @@ We learned that SemVer does not actually fit our project very well, so we decide ### Our new versioning policy -We were accustomed to thinking about major releases of Zarr-Python as epochal events that offer lots of new functionality to users (like a brand new version of the underlying Zarr format), but also require substantial changes to existing code. In other words, while major releases likely contain backwards-incompatible changes, backwards-incompatible changes on their own don't really warrany a major release. +We were accustomed to thinking about major releases of Zarr-Python as epochal events that offer lots of new functionality to users (like a brand new version of the underlying Zarr format), but also require substantial changes to existing code. In other words, while major releases likely contain backwards-incompatible changes, backwards-incompatible changes on their own don't really warrant a major release. [Jacob Tomlinson](https://jacobtomlinson.dev/) extended this framing to a full versioning scheme, which he calls [Intended Effort Versioning](https://jacobtomlinson.dev/effver/), or "EffVer" for short. The basic idea of EffVer is that you version your project according to the expected effort a user will spend in upgrading to that version. From 10b02599c8b3ce6431f271ff79f0adb88d1d2568 Mon Sep 17 00:00:00 2001 From: Davis Bennett Date: Fri, 28 Mar 2025 12:40:28 +0100 Subject: [PATCH 09/11] Update _posts/2025-03-20-switching-to-effver.markdown Co-authored-by: David Stansby --- _posts/2025-03-20-switching-to-effver.markdown | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_posts/2025-03-20-switching-to-effver.markdown b/_posts/2025-03-20-switching-to-effver.markdown index df6e8d3..203f8f9 100644 --- a/_posts/2025-03-20-switching-to-effver.markdown +++ b/_posts/2025-03-20-switching-to-effver.markdown @@ -7,7 +7,7 @@ categories: blog permalink: /versioning-with-effver/ --- -Back in January we released [Zarr-Python 3](https://zarr.readthedocs.io/en/v3.0.0/), the first new version of the library since 2016. While working on this release, we found that Zarr-Python's versioning policy didn't quite fit the needs of the project as it stands today. So we are modifying that versioning policy to make it better suited to the needs of Zarr-Python developers and users. +Back in January we released [Zarr-Python 3](https://zarr.readthedocs.io/en/v3.0.0/), the first new major version of the library since 2016. After making this release, we found that Zarr-Python's versioning policy didn't quite fit the needs of the project as it stands today. So we have modified that versioning policy to make it better suited to the needs of Zarr-Python developers and users. This post will explain what our old versioning policy was, why it wasn't working well for us, and why we are switching to ["Intended Effort Versioning"](https://jacobtomlinson.dev/effver/), or "EffVer". From 1d091b21f082ebb59ae1efa0e823bfa942afdd85 Mon Sep 17 00:00:00 2001 From: Davis Bennett Date: Fri, 28 Mar 2025 12:42:36 +0100 Subject: [PATCH 10/11] Update _posts/2025-03-20-switching-to-effver.markdown Co-authored-by: David Stansby --- _posts/2025-03-20-switching-to-effver.markdown | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_posts/2025-03-20-switching-to-effver.markdown b/_posts/2025-03-20-switching-to-effver.markdown index 203f8f9..89b11bf 100644 --- a/_posts/2025-03-20-switching-to-effver.markdown +++ b/_posts/2025-03-20-switching-to-effver.markdown @@ -25,7 +25,7 @@ Besides fixing bugs in new APIs, we released Zarr-Python 3 with deprecation noti Our users assume that major releases Zarr-Python will contain sweeping changes, not tiny adjustments to public APIs. So releasing version 4 of Zarr-Python because we changed the default values of a few functions would likely confuse people. -We learned that SemVer does not actually fit our project very well, so we decided to update the versioning policy accordingly. If you are interested in the developer discussion about this topic, see this [Github issue](https://github.com/zarr-developers/zarr-python/issues/2889). +We learned that SemVer does not actually fit our project very well, so we decided to update the versioning policy accordingly. If you are interested in the developer discussion about this topic, see [Github issue 2889](https://github.com/zarr-developers/zarr-python/issues/2889). ### Our new versioning policy From e191f9656e488d39648d7776187911e60667702c Mon Sep 17 00:00:00 2001 From: Davis Vann Bennett Date: Fri, 28 Mar 2025 13:44:31 +0100 Subject: [PATCH 11/11] prose --- _posts/2025-03-20-switching-to-effver.markdown | 10 ++++------ 1 file changed, 4 insertions(+), 6 deletions(-) diff --git a/_posts/2025-03-20-switching-to-effver.markdown b/_posts/2025-03-20-switching-to-effver.markdown index 89b11bf..4239e71 100644 --- a/_posts/2025-03-20-switching-to-effver.markdown +++ b/_posts/2025-03-20-switching-to-effver.markdown @@ -19,13 +19,11 @@ The old Zarr-Python versioning policy was effectively [Semantic Versioning](http The impetus for releasing Zarr-Python 3 was to support a new version of the Zarr format. So Zarr-Python 3 was released with a lot of new APIs; some of these APIs have bugs or warts. -For example, we released some functions that *should* have consistent default values, but due to developer error (this author's error, in fact) those functions are inconsistent. [The fix](https://github.com/zarr-developers/zarr-python/pull/2819) is simple, in terms of code changes, but it requires breaking changes to our public API. According to SemVer, fixing this would require releasing Zarr-Python 4, only a few months after we released 3. +For example, we released some functions that *should* have consistent default values, but due to developer error (this author's error, in fact) those functions are inconsistent. [The fix](https://github.com/zarr-developers/zarr-python/pull/2819) is simple, in terms of code changes, but it requires breaking changes to our public API. According to SemVer, fixing this bug would require releasing Zarr-Python 4, only a few months after we released 3. Besides fixing bugs in new APIs, we released Zarr-Python 3 with deprecation notices for many old APIs. We would like to eventually remove these routines from Zarr-Python, but we don't think it would match user expectations if we released a new major version of the library just to signify removing code. Again, this is contrary to SemVer. -Our users assume that major releases Zarr-Python will contain sweeping changes, not tiny adjustments to public APIs. So releasing version 4 of Zarr-Python because we changed the default values of a few functions would likely confuse people. - -We learned that SemVer does not actually fit our project very well, so we decided to update the versioning policy accordingly. If you are interested in the developer discussion about this topic, see [Github issue 2889](https://github.com/zarr-developers/zarr-python/issues/2889). +Releasing version 4 of Zarr-Python because we changed the default values of a few functions would likely confuse people. Our users assume that major releases Zarr-Python will contain sweeping changes, not minor refinements of public APIs. This suggests SemVer does not actually fit our project very well, so we decided to update the versioning policy accordingly. If you are interested in the developer discussion about this topic, see [Github issue 2889](https://github.com/zarr-developers/zarr-python/issues/2889). ### Our new versioning policy @@ -37,10 +35,10 @@ We were accustomed to thinking about major releases of Zarr-Python as epochal ev - Minor releases can require some adoption effort from some users. - Patch releases should require no adoption effort from users. -While SemVer indexes code changes by whether they are backwards compatible or not, EffVer indexes changes on how much effort is required for users to adapt to them. Thus EffVer allows us to ship small-but-breaking changes -- like changing default values of some recently-added functions -- in a minor release, so long as we think these changes will be easy for users to integrate. +While SemVer indexes code changes by whether they are backwards compatible or not, EffVer indexes changes on how much effort is required for users to adapt to them. Thus EffVer allows us to ship small-but-breaking changes -- like changing default values of some recently-added functions -- in a minor release, so long as we think these changes will be easy for users to integrate. ### Conclusion -We think switching to EffVer is right for Zarr-Python development. It lets us refine newly-added APIs while reserving major releases for epochal changes, like the Zarr-Python 2 -> 3 transition. +We think switching to EffVer is right for Zarr-Python development. It lets us refine newly-added APIs while reserving major releases for epochal changes, like the Zarr-Python 2 -> 3 transition. If you have any thoughts or concerns about this decision, we would love to hear from you. The best way to reach us is to open an [issue](https://github.com/zarr-developers/zarr-python/issues) or [discussion](https://github.com/zarr-developers/zarr-python/discussions) on our [Github page](https://github.com/zarr-developers/zarr-python). Thanks for your time!