Versioning Releases wiith Rever

[GbotemiB]

This PR contains creating/managing version num on zarr with rever.

Steps:

after making changes in development. To update the version with rever, simply run the following commands in root directory.
$ rever setup
$ rever <the version number>

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/tutorial.rst
• Changes documented in docs/release.rst
• GitHub Actions have all passed
• Test coverage is 100% (Codecov passes)

Fixes #829

[joshmoore]

Thanks for looking into this, @GbotemiB. Can you update the description with the steps that someone would take to use rever?

[Saransh-cpp]

(I am not a maintainer. You can ignore my reviews if the maintainers approve of this. I generally like reading others' code and working on open-source research software 😄)

[Saransh-cpp]

Hmm, is this manually bumping Zarr's version? Remember, Zarr uses VCS to generate versions. This means that -

1. zarr/version.py technically does not exist. It is an autogenerated file, which is generated by setuptools_scm using the git tags available in Zarr's git repository. We should not be editing this autogenerated file manually. Whenever a new git tag is created in Zarr, setuptools_scm automatically picks it up and bumps Zarr's version.
2. setup.py specifies using a VCS version using the use_scm_version argument in setup. Hence, there are no "version" variables that have to be updated in setup.py.

TL;DR: We should not be manually bumping Zarr's version.

[GbotemiB]

thanks for the review.

[joshmoore]

👍 for @Saransh-cpp's review.

[GbotemiB]

Since SCM manages the version on zarr. It wont be necessary to use rever to bump the versions. But if there is a need to use rever to bump versions, I have the steps outlined here.

[jakirkham]

Thanks for the work on this @GbotemiB! 🙏

Would it be possible to incorporate this into our GitHub Actions release process?

Also do you think this would be possible to add to Numcodecs?

[GbotemiB]

Thanks for the work on this @GbotemiB! pray

Would it be possible to incorporate this into our GitHub Actions release process?

Also do you think this would be possible to add to Numcodecs?

Re-ver has support for Github releases. I will look into this.

I will look into bringing it to Numcodecs

[jakirkham]

Definitely we use rever in conda-forge.

Ideally we would include this as a step in GitHub Actions (maybe after this one?). Maybe we would change the trigger (like using a bot command or issue).

There's also some discussion about options for changelog generation in issue ( #829 ). From it a few things (including rever's new workflow) come up. Some of the others are:

• towncrier
• sphinx-github-changelog
• scriv

[joshmoore]

Would it be possible to incorporate this into our GitHub Actions release process?

@jakirkham: do you mean rever in general or would you replace setuptools-scm?

[jakirkham]

Sorry for missing this. What I mean is we can basically do a release from the GitHub UI today. That's incredibly valuable as that keeps things easy for others wanting to release. Think any changes we make to the release log process, should preserve that functionality. Otherwise we are merely trading one pain point for another (simpler changelog management for harder release process)

[jhamman]

This has unfortunately gone stale. Will it be revived or should we close this?