cowork
361b898ca0
Triggered by Reddit feedback (sysadmin user complained that every
release page shows the same install instructions instead of what
actually changed). Two changes:
1) .github/workflows/release.yml: removed ~80 lines of hardcoded
install/docker/helm boilerplate from the release body. Replaced
with a single link to README.md#quick-start (the source of truth
for install instructions). Kept the per-release supply-chain
verification block (Cosign / SLSA / SBOM steps with the version
baked into the commands) — that IS per-release-meaningful and the
kind of content a security-conscious operator actually wants.
generate_release_notes: true unchanged → GitHub auto-generates the
'What's Changed' section from commits between this tag and the
previous one.
2) CHANGELOG.md: replaced 1393-line hand-edited document with a
one-paragraph stub pointing at GitHub Releases as the source of
truth. The old CHANGELOG had drifted (everything since v2.2.0
piled into [unreleased]; tags v2.0.55-v2.0.61 had no entries).
A stale CHANGELOG is worse than no CHANGELOG — signals abandoned
maintenance to operators doing security diligence. Auto-generated
notes from commit messages work here because the project's commit
message convention is already descriptive (see git log v2.0.50..HEAD
for established pattern). Pre-v2.2.0 history preserved at the
v2.2.0 git tag.
Net result: every future release page shows
- 'What's Changed' (auto from commits, per-release-unique)
- 'Verifying this release' (Cosign/SLSA verification, per-release-version)
- One-line link to README install
…instead of the same 80-line install block on every release.
Verification:
- python3 yaml.safe_load(.github/workflows/release.yml): OK
- No internal references to CHANGELOG.md elsewhere in repo
(grep README.md docs/ → empty)
- Release-pipeline change is YAML-only; no Go code touched
Bundle: chore/release-notes-hygiene
1.5 KiB
Changelog
certctl no longer maintains a hand-edited per-version changelog. Per-release notes are auto-generated from commit messages between consecutive tags.
Where to find what changed in a given release:
- GitHub Releases — every tag has an auto-generated "What's Changed" section pulled from the commits between that tag and the previous one, plus per-release supply-chain verification instructions (Cosign / SLSA / SBOM).
git log <prev-tag>..<this-tag> --oneline— same content, locally.
Why no hand-edited CHANGELOG.md:
certctl is solo-developed and pushes directly to master. Maintaining a
hand-edited CHANGELOG meant the file drifted (entries piled into
[unreleased] and never got promoted to per-version sections when tags were
cut). A stale CHANGELOG is worse than no CHANGELOG — it signals abandoned
maintenance to security-conscious operators doing diligence.
The auto-generated release notes work here because commit messages follow a
descriptive convention: <area>: <summary> with a longer body for non-trivial
changes (see git log v2.0.50..HEAD for the established pattern). Anyone
reading the GitHub Releases page can see exactly what landed in each version
without depending on the author to manually update a separate file.
For the historical record: earlier versions (pre-v2.2.0 and the [2.2.0] tag itself) had a hand-edited CHANGELOG. That content is preserved in git history at the v2.2.0 tag.