The release scheme is as follows.
## Tags
A release is created on a tag push. The tag must be prefixed with `v`, e.g., `v0.2.3`.
Tags can be pushed either manually or via `tag.yml` GitHub Action via a press of the button.
Tags can be moved if needed, like this:
```
# Remove tag
git push -d origin v0.2.3 && git tag -d v0.2.3
# Mark current commit with a tag and push
git tag v0.2.3 && git push origin v0.2.3
```
In such a case, the release action will be executed against the new commit and the existing `v0.2.3` release will be moved to Draft status. One would rarely need such a trick, but it's useful to know of it.
## Changelog
On each release, a changelog is generated. The changelog is calculated from Pull Requests merged between a previous semver-looking tag and a newly pushed one. So, given that there was a release `v0.2.2`, on a push of `v0.2.3` changelog will be generated from PRs that were merged since `v0.2.2` until the commit marked with `v0.2.3`.
Changelog format can be easily changed in the `changelog_config.json` file. It is also possible to set up PR grouping by labels or by regex.
## Release
GitHub release is created in status 'Draft' to avoid notifying repository watchers. Repository maintainers must review the release and make it public manually.
## Publishing
On each release, all publishable crates are published to crates.io. Their versions are published as is, i.e. exactly as specified in Cargo.toml's. Because of that, it is possible that the same versions of crates exist in different releases. It gives maintainers the finest control over publishing.
