CHANGELOG generation¶
CHANGELOG.md at the repo root is generated from the conventional-commits history with git-cliff, configured by cliff.toml.
When to regenerate¶
Before cutting each release tag (e.g. release/v0.2). The changelog is not CI-gated for v0.1.1; freshness is on the release operator.
How to regenerate¶
Install git-cliff once (binary release, pipx install git-cliff, or cargo install git-cliff), then from the repo root:
# For the next release (replace v0.2 with the version you're cutting):
git-cliff --tag v0.2 -o CHANGELOG.md
# Stage, commit, and tag as usual; CHANGELOG.md is part of the release commit.
If a release/vX.Y annotated tag already exists at the target SHA, use --ignore-tags 'release/vX.Y' so the section header renders as [vX.Y] (not [release/vX.Y]) and pass the SHA as a RANGE:
Where readers consume it¶
The reader-facing home of the changelog is the public mirror: https://gitlab.com/wagen-public/racket-book-public. Snapshot publication carries CHANGELOG.md across.