mirror of
https://github.com/shankar0123/certctl.git
synced 2026-06-07 16:21:30 +00:00
shankar0123
3247fbcf92
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
32 lines
1.5 KiB
Markdown
32 lines
1.5 KiB
Markdown
# 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](https://github.com/shankar0123/certctl/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](https://github.com/shankar0123/certctl/blob/v2.2.0/CHANGELOG.md)
|
|
at the v2.2.0 tag.
|