Repository navigation
Release Zarr-Python v3.1.6 #3755
Description
Release: 3.1.6
Scheduled Date: 2026/03/17
Priority PRs/issues to complete prior to release
Add any here!
Before release:
- Make sure the release branch (e.g.,
3.1.x) is up to date with any backports. - Make sure that all pull requests which will be included in the release have been properly documented as changelog files in the
changes/directory. - Run
towncrier build --version x.y.zto create the changelog, and commit the result to the release branch. - Check SPEC 0 to see if the minimum supported version of Python or NumPy needs bumping.
- Check to ensure that:
- Deprecated workarounds/codes/tests are removed. Run
grep "# TODO" **/*.pyto find all potential TODOs. - All tests pass in the "Tests" workflow.
- All tests pass in the "GPU Tests" workflow.
- All tests pass in the "Hypothesis" workflow.
- Check that downstream libraries work well (maintainers can make executive decisions about whether all checks are required for this release).
- numcodecs
- Xarray (@jhamman @dcherian @TomNicholas)
- Zarr's upstream compatibility is tested via the Upstream Dev CI worklow.
- Click on the most recent workflow and check that the
upstream-devjob has run and passed.upstream-devis not run on all all workflow runs. - Check that the expected version of Zarr-Python was tested using the
Version Infostep of theupstream-devjob. - If testing on a branch other than
mainis needed, open a PR modifying https://github.com/pydata/xarray/blob/90ee30943aedba66a37856b2332a41264e288c20/ci/install-upstream-wheels.sh#L56 and add therun-upstreamlabel.
- Titiler.Xarray (@maxrjones)
- Modify dependencies for titiler.xarray.
- Modify triggers for running the test workflow.
- Push the branch to the repository and check for the actions for any failures.
- Deprecated workarounds/codes/tests are removed. Run
Release:
- Go to https://github.com/zarr-developers/zarr-python/releases.
- Click "Draft a new release".
- Choose a version number prefixed with a
v(e.g.v0.0.0). For pre-releases, include the appropriate suffix (e.g.v0.0.0a1orv0.0.0rc2). - Set the target branch to the release branch (e.g.,
3.1.x) - Set the description of the release to:
See release notes https://zarr.readthedocs.io/en/stable/release-notes.html#release-0-0-0, replacing the correct version numbers. For pre-release versions, the URL should omit the pre-release suffix, e.g. "a1" or "rc1". - Click on "Generate release notes" to auto-fill the description.
- Make a release by clicking the 'Publish Release' button, this will automatically create a tag too.
- Verify that release workflows succeeded.
- The latest version is correct on PyPI.
- The stable version is correct on ReadTheDocs.
After release:
- Review and merge the pull request on the conda-forge zarr-feedstock that will be automatically generated.
- Party 🎉
Activity
maxrjones commentedon Mar 9, 2026
Anyone object to a release this week? We have a number of bug fixes and performance improvements that people can use.
ianhi commentedon Mar 11, 2026
Xarray all good.
maxrjones commentedon Mar 12, 2026
I pushed the release until tomorrow, just due to time constraints on my part. Plus a Friday the 13th release sounds fun
maxrjones commentedon Mar 13, 2026
For visibility, I was advised against a Friday release on Zulip so we're now releasing on Tuesday
maxrjones commentedon Mar 20, 2026
@zarr-developers/python-core-devs the release didn't propagate to PyPI due to the changes to workflow triggers in #3742. #3794 re-adds the trigger. We have two options:
I'd lean towards option 2, but would defer to the more longstanding devs on this.
d-v-b commentedon Mar 20, 2026
I now regret not asking for a test pypi workflow in #3791☹️
I'm ok manually releasing, and I would also be OK with just incrementing the version and releasing 3.1.7 with this fix. Version numbers are cheaper than rewriting history IMO.
maxrjones commentedon Mar 20, 2026
I'm not sure that would have led us to catch the missing trigger, but it's a good idea anyways. Ultimately it was my responsibility when cutting the release to check everything's setup properly. I'm sorry for having not caught this.
I think missing releases can confuse folks, so I'd prefer a manual release over skipping 3.1.6 on PyPI. Would you be willing to do the upload?
d-v-b commentedon Mar 20, 2026
I'd be happy to! I will probably wait until Monday, to ensure that we don't have a nightmare weekend in case anything breaking slipped through.
d-v-b commentedon Mar 20, 2026
also for posterity the best way to avoid this hiccups is to keep the gears oiled and just release more. we should really aim for weekly or biweekly releases!
maxrjones commentedon Mar 20, 2026
Thanks very much! We don't need to freeze commits to main for this to go well, right?
keewis commentedon Mar 23, 2026
for reference, most of the issues happen when building the package, not during the upload. Thus, if you trigger the build job on pull requests with a label (e.g.
release) you often don't even need to try uploading totest.pypi.org.