zarr-python
zarr-python copied to clipboard
Versioning Releases wiith Rever
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)
Thanks for looking into this, @GbotemiB. Can you update the description with the steps that someone would take to use rever?
:+1: for @Saransh-cpp's review.
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.
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?
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
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 ( https://github.com/zarr-developers/zarr-python/issues/829 ). From it a few things (including rever's new workflow) come up. Some of the others are:
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?
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)
This has unfortunately gone stale. Will it be revived or should we close this?