Release notes are the human-readable summary of what changed in a release — the new features, the fixes, the breaking changes — written for the people who use the product, not the people who built it. This page tells you plainly what release notes are, how they differ from a changelog and a release plan, what a good set includes, and hands you a template. Then the honest part: release notes are written once at ship time and immediately start disagreeing with the spec and decisions they describe, because nothing connects them back.
Release notes are a user-facing announcement of what a release delivers, in plain language: what's new, what's improved, what's fixed, and anything that requires action (a breaking change, a migration). The job is to let someone decide "do I care about this update, and do I need to do anything?" without reading a commit log. Good product release notes lead with value ("export threads to PDF"), not implementation ("added a PDF rendering service").
They're distinct from two things people conflate them with. A changelog is the terse, often developer-facing running list of every change (frequently auto-generated). A release plan is the forward-looking document — what will ship, when, with what rollout. Release notes are the backward-looking announcement once it has.
Three artifacts around a release, easy to blur. The difference is audience and direction in time.
| Artifact | For whom | Direction |
|---|---|---|
| Release notes | Users / customers | Backward — what shipped |
| Changelog | Developers, terse | Backward — every change |
| Release plan | Internal team | Forward — what will ship |
This is the whole template — it works in an in-app changelog, an email, or a docs page. The next section is about what changes when each note links back to the spec and decisions it describes.
The release version (or name) and the date it shipped. The anchor everything else hangs off, and what a user references when they report something on "the version from last Tuesday."
One or two lines on what this release is about, framed as outcomes. If a reader stops after this, they should still know whether the update matters to them.
Each new capability in user terms — what it lets them do, not how it's built. A line or two each, linking to deeper docs where it helps.
Enhancements to existing behavior — faster, clearer, more reliable. The "we heard you" section; tie these to the feedback or requests that prompted them where you can.
Notable bugs resolved, in plain language. You don't list every patch — you list the ones a user noticed or asked about.
Anything that changes behavior they depend on, or requires a migration, a re-auth, an updated integration. The single most important section when it applies — bury it and you generate support tickets.
That's the template. Below: why release notes drift from what actually shipped — and how we keep them tied to it.
Release notes are a snapshot of what a release was supposed to be at ship time. But the spec a note describes, and the decisions under it, keep changing — and nothing connects the note back. Draftlize keeps the thread.
In Draftlize a release note isn't free text typed from memory — it's generated from the cards that actually shipped: the features, the fixes, the decisions behind them. The note links to the spec it describes, so "what did this release actually change" is a graph query, not an archaeology dig through tickets.
A feature gets pulled the day before ship, or a decision reverses post-release. Because the note links to the spec, it auto-flags stale instead of confidently announcing something that didn't ship — the embarrassing release-note bug that no spreadsheet catches.
Ask Claude Code or Cursor to draft the next release notes over MCP and it reads the cards that actually changed in this release — so the draft starts from the real diff of decisions and specs, not a half-remembered list someone reconstructs at 5pm on ship day.
Release notes are written once and never updated. The trouble is the release they describe is still changing right up to ship.Keep the format. Generate the notes from what actually shipped.
Release notes are user-facing and curated — they explain what a release means in plain language, leading with value. A changelog is a terse, often developer-facing and frequently auto-generated running list of every change. Release notes are a story for users; a changelog is a record for builders.
A release plan is forward-looking — what will ship, when, with what rollout and rollback. Release notes are backward-looking — what did ship, written once it has. The plan is internal and operational; the notes are external and announcement-shaped.
Version and date, a value-led summary, new features in user terms, improvements, notable fixes, and — most important when it applies — breaking changes or required actions. Lead with what the update lets someone do, not how it was built.
Match your release cadence. Continuous-delivery teams often batch user-visible changes into a periodic digest so users are not pinged on every deploy; scheduled releases publish notes per release. The rule is consistency, so users learn where to look.
Take the template above, or let Draftlize draft each release's notes from the cards that actually changed — linked to the specs they describe, so a late scope cut flags the note instead of shipping a lie.
Start free with $5