Release notes generators: 5 ways to automate release notes

A release notes generator turns the history of a project, usually its commits or merged pull requests, into written release notes. It saves the slowest part of shipping: sitting down after a release to work out what changed. Generators range from a one-line git command to tools that use AI to write full sentences. They differ in how much of the editing they leave to you.

This guide compares five ways to automate release notes, explains where each one falls short, and lists what to check before you publish anything a machine wrote.

What a generator can and cannot know

Every generator starts from the same raw material: what developers wrote while they worked. Commit messages, pull request titles and labels are all it has. A generator can sort, group and rephrase that text. It cannot know that a change matters to customers if nobody said so, or that a one-line fix hides a behaviour change.

That is why the quality of the output follows the quality of the input, and why a person should always review the result.

Five ways to automate release notes

1. Write them by hand

Not automation, but the baseline. Hand-written notes are as good as the writer and as consistent as their habits. The cost is time, and the usual failure is that the notes simply do not get written under release pressure.

2. Format the git log

The simplest automation is a command that lists the commit subjects between two tags:

git log v1.1.0..v1.2.0 --pretty=format:"- %s (%h)"

It takes seconds and needs no setup. The output is a raw list in the language of the codebase, including every chore and refactor, so it works as a starting point but not as something to send to customers.

3. Use Conventional Commits tooling

The Conventional Commits specification gives commit messages a structure: a type such as feat or fix, an optional scope, and a marker for breaking changes.

feat: add pdf export
fix(auth): stop the oauth redirect loop
feat!: rename the theme config key

Tools build on these prefixes. conventional-changelog generates changelogs and release notes from commit messages. release-please and semantic-release also use the prefixes to decide the next version number: release-please opens a release pull request for you to merge, while semantic-release publishes the release itself from your CI. This suits teams that already follow the convention strictly (release-please, for example, assumes you use Conventional Commit messages). The output is still written in developer language, and it is only as consistent as the commit messages behind it.

4. Use GitHub's generated release notes

When you create a release on GitHub you can click Generate release notes. The result includes a list of merged pull requests, a list of contributors and a link to the full changelog, and you can choose which previous tag to compare against. A configuration file at .github/release.yml can group pull requests into categories by label. It is built into GitHub and suits open source projects. The text is still pull request titles, so it reads as a changelog for developers more than release notes for customers.

5. Generate them with AI

AI tools send commit messages, pull request titles or descriptions to a language model and get back sentences written for a reader. This is the only automated option that changes the voice, turning "fix oauth redirect loop" into a line a customer understands. The risks are real too. A model can state something the change did not do, miss why a change matters, or sound more certain than the source text allows.

How the five compare

Approach	Setup	Reads like	Needs discipline	Main risk
By hand	None	Whatever you write	Yes, to do it at all	Skipped under pressure
Formatted git log	One command	Commit log	No	Noise and jargon
Conventional Commits tools	Convention and tooling	Generated developer notes	Yes, on every commit	Output is only as consistent as the messages
GitHub generated notes	Optional label config	List of pull requests	Good PR titles and labels	Too raw for customers
AI generation	Connect a repository	Readable sentences	Review of the output	Inaccurate or overconfident wording

A rough illustration of the trade-off, not measured data.

How to choose

If you maintain a library and your readers are developers, start with Conventional Commits or GitHub's generated notes and keep a Keep a Changelog file.
If you ship an application to non-technical users, you need prose. Choose hand-written or AI-assisted notes.
If you have both audiences, generate a developer version and a user version from the same commits.
If your commit messages are inconsistent, do not expect any generator to hide that. Fix the habit first.

What to check in AI-written release notes

Treat the draft as a first pass from a quick colleague who has not seen your product:

Check every claim against the pull request. If the note says something the change does not do, remove it.
Look for breaking changes the draft may have missed, and put them at the top.
Replace internal names, ticket numbers and jargon the reader will not know.
Confirm the version number and the date.
Make sure nothing private appears in the text, because commit messages are sent to a model to be summarised.
Keep a person responsible for sign-off before it is published.

For guidance on the wording itself, see how to write a changelog.

Sources

The descriptions above come from each project's own documentation:

Where ReleaseTale fits

ReleaseTale is an AI option built around that review step. You choose the commits for a release; it reads the commit messages, pull request titles and descriptions, and file names, then drafts a user version and a developer version side by side. You edit either one before saving. Its limits are worth knowing: it does not read diffs or source code, so it cannot know about effects nobody described, and it works with GitHub repositories only. The Free plan includes three changelogs in total. Details are on the pricing page, and the examples page shows the output.