There is no CHANGELOG anywhere in the repo, and no tooling configured to produce one — zero hits for towncrier, git-cliff, release-please, commitizen or semantic-release across pyproject.toml, Makefile and .github/.
Release notes currently come solely from gh release create --generate-notes (release.yml:209), which emits raw ungrouped PR titles over the range since the previous tag.
Why it matters now
Why it should be cheap
The repo already uses disciplined conventional commits (fix(google):, refactor(checks)!:, chore(deps):), including the ! breaking marker. That is exactly the input git-cliff or release-please consumes, so most of the work is already done — it just needs a config and a workflow step.
Open decisions
- Tool: git-cliff (generates from git history, no per-PR fragment files, minimal contributor friction) vs release-please (also automates the version bump and release PR, but overlaps with the existing
release.yml). Given release.yml already handles bumping and publishing, git-cliff is the smaller change.
- Granularity: one root
CHANGELOG.md, or one per lib. The repo versions the 5 libs independently and tags per package (<pkg>/v<version>), which argues for per-lib — but a single root file is far easier for users to read. A root file grouped by package is a reasonable middle.
- Whether to backfill history for the beta series or start the changelog at the RC.
Related
#2732 (meta-package has no prior tag). Should land before the RC is cut.
There is no
CHANGELOGanywhere in the repo, and no tooling configured to produce one — zero hits for towncrier, git-cliff, release-please, commitizen or semantic-release acrosspyproject.toml,Makefileand.github/.Release notes currently come solely from
gh release create --generate-notes(release.yml:209), which emits raw ungrouped PR titles over the range since the previous tag.Why it matters now
--generate-notesrun will diff against nothing and dump the entire repo history.Why it should be cheap
The repo already uses disciplined conventional commits (
fix(google):,refactor(checks)!:,chore(deps):), including the!breaking marker. That is exactly the input git-cliff or release-please consumes, so most of the work is already done — it just needs a config and a workflow step.Open decisions
release.yml). Givenrelease.ymlalready handles bumping and publishing, git-cliff is the smaller change.CHANGELOG.md, or one per lib. The repo versions the 5 libs independently and tags per package (<pkg>/v<version>), which argues for per-lib — but a single root file is far easier for users to read. A root file grouped by package is a reasonable middle.Related
#2732 (meta-package has no prior tag). Should land before the RC is cut.