GitHub's release notes aren't changelogs

Echo · August 19, 2026

Tag a release on GitHub, click "Generate release notes", and you get a document in about a second. It lists every merged pull request since the last tag. It credits the contributors. It links a full compare view.

Then you paste it into an email to customers, and it falls apart.

A pull request title describes the work

Here is what the generator gives you, near enough:

What's Changed

fix: null check in session middleware by @dana in #412

chore: bump libfoo to 3.2.1 by @sam in #413

feat: add retry to webhook dispatch by @dana in #414

Every line is true. Every line was written by an engineer, for engineers, at the moment they opened the pull request. None of them says what a person outside the team can now do that they could not do last week.

An empty parcel depot at night, a conveyor belt carrying identical unmarked boxes in a single line — Everything that shipped, in the order it arrived.

The generator is honest about this. It is a changelog of pull requests. The trouble starts when a team sends it to customers. Teams do, because the real version takes an afternoon nobody has during release week. This is the same failure that makes most changelogs go unread: one document, written once, aimed at whoever happens to open it.

It can only see one repository

The deeper limit is structural. GitHub generates notes per repository, because a release is a tag on a repository. That is the only unit it has.

Your product is not shaped like that. Guest checkout goes live and the work sits in the web app, the API, a shared payments library, and an infrastructure config. Four repositories, four sets of release notes, four separate lists. Nobody outside the team can reassemble the feature from those pieces, and that reconstruction is the job everyone quietly does by hand.

You can group by label. You can write a release.yml that sorts pull requests into Features and Bug Fixes. It is worth doing. It still sorts the same titles into tidier piles, and it still stops at the repository boundary.

Four office towers at night seen across a river, only one of them with its windows lit — The generator sees the repository it was pointed at, and nothing beside it.

What has to happen instead

Someone has to read the diff and decide what it means. That step is the whole job, and it is the step the generator skips.

Echo does it from the same raw material GitHub uses, plus the parts GitHub cannot reach. It reads the diffs, the pull requests, and the issues they close across every repository in the release. It works out which changes belong to the same user-facing story.

Then it writes that story four times. Once for the team. Once for customers. Once for developers, with the breaking changes and the migration path. Once as structured data an agent can read.

Generated release notes remain the right tool for the audience they were built for. Engineers on the repository want the list, and the compare link, and the contributor credits.

A railway switchyard at dawn seen from an overpass, one track fanning out into four — One release. Four people who need to hear about it differently.

Everyone else needs a sentence that starts with what they can now do.

The list is free and takes a second. The account of what changed is the part you keep paying for by hand. That second part is what Echo automates.