Add a release checklist issue template

[maxrjones]

This is an example of the release checklist template proposed in #3209, based on https://github.com/GenericMappingTools/pygmt/blob/main/.github/ISSUE_TEMPLATE/4-release_checklist.md.

TODO:

• Add unit tests and/or doctests in docstrings
• Add docstrings and API docs for any new/modified user-facing classes and functions
• New/modified features documented in docs/user-guide/*.rst
• Changes documented as a new file in changes/
• GitHub Actions have all passed
• Test coverage is 100% (Codecov passes)

[d-v-b]

@zarr-developers/python-core-devs since we would like to release 3.1.0 soon, it would be great to get a lot of eyes on this

[dstansby]

Sorry, I don't have time to review in detail. I'm 👍 to moving the checklist here, but info at https://zarr.readthedocs.io/en/stable/developers/contributing.html#release-procedure should be removed at the same time to make sure we're not duplicating info across different places.

[maxrjones]

Sorry, I don't have time to review in detail. I'm 👍 to moving the checklist here, but info at zarr.readthedocs.io/en/stable/developers/contributing.html#release-procedure should be removed at the same time to make sure we're not duplicating info across different places.

Thanks for the general review! https://github.com/zarr-developers/zarr-python/pull/3210/files#diff-4c43ecea097324201785238a3e9969e3490fc89d8f8a5a0363439c6bc893e354 includes a removal of the duplication from the contributing guide.

it would be great to get a lot of eyes on this

FWIW this change doesn't touch the codebase and can be easily reverted or modified. My recommendation would be to not spend too much time trying to make this perfect in advance, try it out for 3.1.0 release, and edit the template in a follow-up based on the smoothness of the release process.

To help the review, I temporarily enabled issues on my fork so you can see what it looks like in practice:

• Selecting the template: https://github.com/maxrjones/zarr-python/issues/new/choose
• Previewing the release checklist: https://github.com/maxrjones/zarr-python/issues/new?template=release-checklist.md

[d-v-b]

FWIW this change doesn't touch the codebase and can be easily reverted or modified. My recommendation would be to not spend too much time trying to make this perfect in advance, try it out for 3.1.0 release, and edit the template in a follow-up based on the smoothness of the release process.

💯 , I just want to ensure that this effort gets high visibility among the other devs

[jhamman]

Would a failing upstream dev test block a release if it was not related to Zarr?

[maxrjones]

e9157f3 (#3210) updates the downstream component of the checklist to follow the structure that's worked pretty well for GMT. The developers of downstream libraries are pinged as part of the release checklist issue. Zarr-Python devs can decide whether to wait for all those downstream checks to be completed and whether any failures should be blocking.

[jhamman]

I love this. I do think we should be careful not to put too many hard blockers on releasing (e.g. tests in other packages). So long as we can use judgement on those, I'm all for this checklist.

[d-v-b]

this looks great, let me know if you need more time with or if we can merge as-is

[maxrjones]

this looks great, let me know if you need more time with or if we can merge as-is

not sure if this was meant for me, but I don't have any planned changes for this PR