Software Release Notes Template
Three notes, a migration guide, and the register that names every published page this release just left saying something false.
Free download · No account needed
Documentation Impact Note
Release [version], cut [date]
The release, in three counts
| Merged pull requests since the last tag | — |
| Reader-facing changes | — |
| Published pages those changes touch | — |
| Impact rows, one per change and page | — |
| Rows where a page now says something false | — |
| Rows where a page is missing a section | — |
| Monthly reads on the pages carrying a falsehood | — |
The rows that block publication
Every falsehood on a page above your reads threshold, with what it asserts today and what it has to assert instead. Both lines, written while the diff is open. This is the field a release note never carries and an audit spends forty hours reconstructing.
What each area owes
Rows per documentation area, each against the named person who owns it. A name, not a queue called docs.
What the mapping cost
Minutes per change to map, minutes per page to correct, and the same two figures multiplied by this product’s release cadence. Then, if the set has ever been audited retrospectively, what that cost instead.
Version number
The breaking count against the increment about to be tagged, and whether the two agree.
Rows carried forward
Everything still open, with an age in days, at the top of the next cycle rather than in a backlog.
Thornbeck 4.7.0 shipped on 12 February 2026 with 71 merged pull requests, 23 of which a reader could observe. Those 23 touch 23 published pages, and 19 of them now say something false: a flag that no longer exists, a default given as five minutes when it is fifteen, a scrape path that returns 404. Ninety thousand and six reads a month land on those 19 pages. Naming them took 69 minutes, because every diff was still open.
The same answer costs 40.6 hours to reconstruct a year later. That is what a documentation audit spends checking 128 pages against the shipped binary before it writes a word, and it turned up 70 findings that were each observable on the day they shipped. This pack records the answer while it is still cheap. One register row per change, one impact row per change and page, and a state on every one of them.
Two more checks read the same register. Six of the 23 changes remove, rename or newly require something, and semantic versioning reserves a major increment for exactly that, so a release tagged 4.7.0 makes a claim its own register disproves. Six changes carry no ticket, so a writer working from the tracker would have published without a security fix, a removed subcommand and a new endpoint. A field a specification never filled in is a different problem from a page that drifted, and it belongs to the OpenAPI gap workup.
What's in the pack
Change Register
One row per reader-facing change, with the breaking flag the version check reads and a reference where no ticket exists.
Documentation Impact
One row per change and page: what it asserts today, what it has to say, the monthly reads, an owner.
Publication Checklist
Ten gates the notes clear before publishing, each carrying a count read off the register rather than somebody's tick.
Release Notes by Audience
Three notes cut by what each reader can observe, using the six changelog categories, removals first.
Breaking Change Notice
The changes that need action, sent ahead of the release, with the version-number contradiction stated at the top.
Migration Guide
One entry per breaking change and nothing else, ordered so the failures that would page somebody get fixed first.
Documentation Impact Note
The counts, the blocking rows, what each area owes, and the mapping cost against an audit later.
How it works
- 1
Open or download
Edit with AI installs the pack as a private Space and asks for your merge log, your documentation and the version you are about to tag. Download gives you the blank files, no account.
- 2
Filter the merge log
Every merged change since the last tag is either observable by a reader or carries a recorded reason it is not. The merge log is the source, because changes ship without tickets.
- 3
Name the pages
For each observable change, the published set is searched for what it renamed, removed or added, and every hit becomes a row: a page now saying something false, or a page missing a section.
- 4
Publish and carry forward
The three documents are written from the register, the falsehoods on your busiest pages are corrected first, and whatever is still open opens the next cycle with an age on it.
Frequently asked questions
What does it need from me?
The merged pull requests or commits since your last tag with their titles, your documentation in whatever form is searchable, and the version you are about to tag. Per-page traffic if you have it, because it decides which corrections block publication. Tickets are useful context and are not the filter, because plenty of changes ship without one and plenty of tickets close without shipping anything.
What format are the downloaded files?
Four Word documents and three CSV sheets, zipped. The documents open in Word, Pages and Google Docs; the sheets open in Excel, Numbers and Sheets. Nothing needs converting and nothing is in a format you have to look up. Add a PDF query string if you want to read rather than fill in.
What does Edit with AI actually do?
It installs this pack as a private Space, then runs the two passes that cost the most by hand: sorting your merge log into what a reader can observe, and searching your published pages for every name the release changed. You get the register filled in, with the rows that block publication at the top.
We already publish release notes for customers. Is this different?
Different job, different reader. Announcing a release to accounts, ranked by how many will notice, is the product release notes pack. This one is for whoever owns the documentation, and its output is the list of pages the release just made wrong.
What happens to deprecations?
They keep working, so they are not breaking changes and get no migration entry. The register records the version each one is removed in, which makes the next major release's migration guide writable in advance. Setting the notice period is the deprecation policy pack; tracking which supported versions still carry the old behavior is the versioning and release mapping pack.
Can it decide our version number for us?
It counts the breaking changes and says which increment that count requires. It does not retag anything. Retagging moves the deprecation clock for everything currently marked for removal in the next major line, which makes it a decision for whoever owns the release rather than a correction.
Is any of this free?
The download is free and needs no account: the real documents and sheets, blank, as Word and CSV. Edit with AI creates a free account and fills them in from your own release. The pack in the zip is the same pack the AI works from, not a trimmed sample of it.
Find out which pages this release just broke
Download the blank Change Register, Documentation Impact sheet and Publication Checklist as Word and CSV, or have River fill them in from your own merge log.
Edit with AI