Nobody approved that release note: how teams ship changelogs without the chaos

A practical walkthrough of the approval gate for release notes — and why a review step beats commit-prefix discipline when more than one person merges to main.

Most teams do not have a release-note problem until they have a second maintainer.

Solo devs publish from memory. It works — until three people merge to main and "who wrote that release note, and did anyone check it?" becomes a real question, usually asked after the embarrassing typo is already public.

The gate is the whole ballgame

CI scripts cannot give you a human gate. Release Please and semantic-release publish whatever the commit prefixes say: no Slack ping, no second pair of eyes, and when someone forgets feat: or fix:, the output is garbage.

A working approval workflow looks like this:

1. Release trigger — branch, tag, or on demand. One generation = one draft (feature-branch commits never burn your quota).
2. Classified draft — Features / Fixes / Breaking, each with a verifiable reason attached.
3. Human review — nothing reaches GitHub Releases until someone approves it.
4. Publish — the approved draft lands as the release note.

The discipline is boring on purpose. The interesting part is that the draft arrives classified with reasons, so the reviewer is checking a decision, not writing prose from scratch.

What to look for when evaluating tooling

• Least privilege. The GitHub App should read commit metadata and diffs only — never store, redistribute, or train on your source code.
• Quota semantics. Confirm what actually consumes your monthly generations. Branch noise should not.
• Free tier honesty. A public-repo free plan (a few drafts/month, watermark, no credit card) tells you more about the product than any demo video.
• Team features. Approval workflow and notifications only matter once more than one person merges.

Try the worked example

You can see a complete worked example on the homepage without creating an account - a real repository, a classified draft, and the approval step shown end to end.

Full write-up (canonical source): https://changelogforge.app/press/github-release-automation-2026/

---

This article is a value-first walkthrough of a workflow pattern. The tool behind the worked example is ChangelogForge (https://changelogforge.app/), a product of Universal Global Services Ltd (London, Companies House No 17423506). Prices in USD excl. VAT.