If your PR labels are consistent, your release notes can be effortless. Labeling is the hidden infrastructure of good release communication.
Why labels work so well
Labels are already part of your workflow: they're attached to PRs and issues, reviewed by the team, and carry intent. That makes them a perfect input for release note automation.
A clear label taxonomy turns "what merged" into "what shipped."
Build a label taxonomy that writes the notes for you
Keep it small and meaningful. For most teams, this is enough:
feature-- user-visible additionsimprovement-- quality or performance upgradesfix-- bug fixessecurity-- anything risky or sensitivedeprecated-- changes that remove or sunset behavior
Add internal or infra if you want a private bucket.
Enforce the labels
Release notes only work if labels are reliable. A few enforcement tricks:
- Use a PR template that asks "What label applies?"
- Add a bot that warns if no release label exists.
- Make "label applied" part of the review checklist.
The goal is not bureaucracy. The goal is a clean dataset.
A simple label-to-section map
Keep the mapping explicit so writers know what will appear:
release_sections:
feature: Added
improvement: Changed
fix: Fixed
security: Security
deprecated: Deprecated
fallback_section: Internal
If a label doesn't exist, it goes to the fallback. That keeps the draft coherent without blocking the merge.
The release note flow
- PRs merge with labels.
- Release draft collects them into sections.
- You edit the wording and add context.
- The notes publish with a narrative voice.
This flow keeps humans in control while removing the busywork.
ReleaseMind and labels
ReleaseMind pulls labeled PRs into a draft, groups them into sections, and suggests human-readable language. You choose what to publish, but the draft is already coherent.
