A release note should tell readers whether they need to change a setting, update an integration, or expect different behavior. Automation can collect changes while the work is fresh. The editorial decision is which changes matter to which audience and what action each reader needs to take.
Capture the impact when the change is proposed
Ask contributors to record the affected audience, the visible change, and any required migration step in the pull request. For example, “Webhook requests now retry after a timeout” is a useful starting point. A publishable note would also explain whether customers need to make their webhook handlers safe to retry.
Decide whether the notes describe a versioned artifact or a feature rollout. A feature can ship behind a flag and become available later. If those milestones differ, tie developer notes to the release and customer announcements to the actual rollout.
Select the tool by how you publish
| Tool | Best fit to evaluate |
|---|---|
| GitHub Releases | A tagged repository release that needs a generated list of merged changes as a starting point |
| Release Drafter | A GitHub repository that wants a draft maintained as changes merge |
| Changesets | A package repository that needs version decisions and changelog entries tracked together |
When notes are generated from pull requests, review internal labels and references before publishing. When notes are captured per package, check how the tool describes changes to dependent packages and whether consumers can find their own migration path.
Run your next release through the workflow and ask support and a package consumer to read the draft separately. Both should be able to identify the affected version and explain what they would do next. Their disagreements tell you where an automated list still needs editing.