Add RELEASE.md #611
Add RELEASE.md #611
Conversation
Add a file that describes release proccess
| - Tag the commit as `3.29.6-scylla` if publishing docs, and `3.29.6` for the driver if applicable. | ||
|
|
||
| 6) Publish checklist | ||
| - Push tags and commit. |
There was a problem hiding this comment.
Maybe I don't have the latest info, but isn't it worth mentioning that this push should be atomic? Something like git push --atomic origin master 3.26.8-scylla to push commit and tag together
| - Publish wheels/sdist to the package index. | ||
| - Trigger docs build for the new tag/branch. |
There was a problem hiding this comment.
Could you elaborate on those points? You told what to do, but not how to do it.
I never had to do that when releasing, it was done automatically. Is that something we need to do manually now?
|
|
||
| 5) Commit and tag | ||
| - Commit with an imperative subject, e.g. `Release 3.29.6: changelog, version and documentation`. | ||
| - Tag the commit as `3.29.6-scylla` if publishing docs, and `3.29.6` for the driver if applicable. |
There was a problem hiding this comment.
WDYM? It thought we only used -scylla tags. When do we use tags like 3.29.6?
|
|
||
| 4) Tests and validation | ||
| - Run unit tests: `uv run pytest tests/unit`. | ||
| - Spot-check relevant integration tests if new protocol or cluster behavior was touched. |
There was a problem hiding this comment.
What's the added value of that if we run them before merging PRs?
| 4) Tests and validation | ||
| - Run unit tests: `uv run pytest tests/unit`. | ||
| - Spot-check relevant integration tests if new protocol or cluster behavior was touched. | ||
| - Build artifacts to confirm packaging still works: `uv run python -m build`. |
| Follow these steps to prepare a new release (example: `3.29.6`): | ||
|
|
||
| 1) Version bump | ||
| - Update `cassandra/__init__.py` `__version_info__`/`__version__`. |
There was a problem hiding this comment.
__version__ is generated from __version_info__. How do you want a maintainer to update it?
|
|
||
| 1) Version bump | ||
| - Update `cassandra/__init__.py` `__version_info__`/`__version__`. | ||
| - Add new tag with `-scylla` postfix to `docs/conf.py` `TAGS` and set `LATEST_VERSION`. |
| 1) Version bump | ||
| - Update `cassandra/__init__.py` `__version_info__`/`__version__`. | ||
| - Add new tag with `-scylla` postfix to `docs/conf.py` `TAGS` and set `LATEST_VERSION`. | ||
| - Refresh any user-facing version strings (e.g. `docs/installation.rst`). |
There was a problem hiding this comment.
The important purpose of such guide is to provide a comprehensive list of such places, to avoid missing some when releasing.
|
|
||
| 2) Changelog | ||
| - Add a new section at the top of `CHANGELOG.rst` with the release date. | ||
| - List each merged PR since the previous release in the format `* <description> (#<PR-ID>)`. |
There was a problem hiding this comment.
I really wish we started doing nicer release notes, like we do in Rust Driver, or like Operator team does (https://forum.scylladb.com/t/release-scylladb-operator-1-19-0/5188 )
Just a list of PRs is not very friendly.
| - List each merged PR since the previous release in the format `* <description> (#<PR-ID>)`. | ||
|
|
||
| 3) Dependency/docs metadata | ||
| - Update `docs/conf.py` multiversion tag list if new published doc tags are required. |
There was a problem hiding this comment.
What is multiversion tag list? How is it different from things described in step 1 (TAGS, LATEST_VERSION)?
Add a doc that describes release proccess
Pre-review checklist
I added relevant tests for new features and bug fixes.I have provided docstrings for the public items that I want to introduce.I have adjusted the documentation in./docs/source/.I added appropriateFixes:annotations to PR description.