Release Notes Template and Ten Good Examples

A good release note answers three questions for the person reading it: what is new, what works better or differently, and is there anything I need to do. The template that does this reliably is a heading with the version and date, one sentence summarising the release, then short sections for New, Improved and Fixed, and a separate section for anything that needs action. Each line describes a change in terms of what the reader can now do, not what the team changed in the code. The template and ten examples are below.

What release notes are for, and who reads them

Release notes are a message to people who did not see the work happen. They decide whether someone tries the new feature, whether a support agent can answer a question without asking engineering, and whether an administrator knows to change a setting before Monday. Most products have several readers at once:

• Customers and end users, who want to know what they can now do and whether anything they rely on changed.
• Administrators, who need warnings about settings, permissions, removals and anything that needs their action.
• Your support and sales teams, who get asked about the release first and need the same words the customer sees.
• Developers integrating with you, who need breaking changes, deprecations and version numbers stated exactly.

If those readers need very different things, write two versions from the same list of changes rather than one note that serves nobody: a customer note, and a technical note or changelog for developers.

The structure

1. Heading: product name, version and release date. The date matters more than people think; it is how support matches a complaint to a release.
2. Summary: one or two sentences on what this release is about. If you cannot write it, the release has no theme, which is fine; say what the biggest change is.
3. Action needed: anything the reader must do, and by when. It goes above the lists, not at the bottom, because it is the part people must not miss.
4. New: features that did not exist before.
5. Improved: changes to something that already existed.
6. Fixed: bugs that no longer happen, described by the symptom the user saw.
7. Known issues: what is still wrong, with a workaround if there is one.
8. Where to find more: a link to the help article, the full changelog, or a way to give feedback.

Tone: the rules that make them readable

• Lead with what the reader can do. “You can now export invoices as CSV” beats “Added CSV export functionality to the invoicing module”.
• Describe fixes by the symptom. “The app no longer logs you out when you switch to another app” tells the user whether their problem is fixed. “Fixed session token refresh race” does not.
• One change per line, one sentence per change. If it needs a paragraph, it needs a help article, and the note links to it.
• No internal names. Ticket numbers, codenames and file paths belong in the technical changelog.
• Be exact about anything that could break. Name the setting, the endpoint, the date, and what happens if nobody acts.
• No marketing. Adjectives like “powerful” and “exciting” cost the reader time and add nothing. Let the change speak.
• Leave out what nobody outside the team will notice: refactors, dependency upgrades, build changes.

A release notes template you can copy

# [Product] [version] — [date, e.g. 28 September 2026]

[One or two sentences: what this release is about, or its biggest change.]

## Action needed
- [What the reader must do, by when, and what happens if they do not.]

## New
- [You can now … ] ([link to help article])

## Improved
- [What works better, and how the reader will notice.]

## Fixed
- [The symptom the user saw] no longer happens.

## Known issues
- [What is still wrong.] Workaround: [what to do meanwhile].

Questions or feedback: [link or address]

Delete any section with nothing in it. A release with only fixes is a heading, a summary and a Fixed list, and that is a perfectly good release note.

The short version for app stores

App stores give you much less room, so write the short version from the long one, not the other way round. Apple’s App Store Connect has a What’s New in This Version↗ (opens in a new tab) field of up to 4,000 characters, required for every version after the first.

Google Play is tighter: its release guidance↗ (opens in a new tab) allows up to 500 Unicode characters per language, and asks you to inform users about the update rather than use the notes for promotion. In 500 characters, keep the action-needed line and the two or three changes a user is most likely to notice, and link to the rest from inside the app.

Release notes vs a changelog

Keep a Changelog↗ (opens in a new tab) defines a changelog as a curated, chronologically ordered list of notable changes for each version of a project. It groups changes under six headings, Added, Changed, Deprecated, Removed, Fixed and Security, keeps an Unreleased section at the top, and warns against pasting commit logs, which are full of noise. A changelog is usually a single running file, complete and precise, read mostly by developers.

Release notes are selective and written for a particular reader at a particular release. They borrow the changelog’s best habits, grouping, dates and latest first, but leave out what the reader does not need. If you publish an API or library, number your versions with Semantic Versioning↗ (opens in a new tab), so that a major version signals an incompatible change, a minor one new backward-compatible functionality, and a patch backward-compatible fixes; your release notes can then say “this is a major release” and mean something exact.

Ten release notes examples

The products below are invented, so the examples can show one technique each without borrowing anyone’s real notes. Each is a single entry, the size of one line in a real release.

1. Invoicing app, New: “You can now send an invoice in the customer’s own currency. Choose the currency when you create the invoice; totals and tax are shown in both.” It says what, where and what the reader will see.
2. Invoicing app, Fixed: “Invoices with more than 50 lines no longer lose their last line when exported to PDF.” The symptom, stated exactly enough that a customer who hit it will recognise it.
3. Fitness mobile app, Improved: “Workouts now sync in the background, so your history is up to date when you open the app.” The benefit, not the mechanism.
4. Fitness mobile app, Known issue: “On some Android 13 phones, heart-rate data from a paired watch arrives a few minutes late. Your totals are correct once it arrives.” Honest, and it heads off support tickets.
5. Team chat tool, Action needed: “From 1 November, guests can no longer create channels. If your guests need to, change their role in Settings before then.” Date, change, consequence, what to do.
6. Team chat tool, Removed: “The old desktop app for Windows 7 is no longer updated. It keeps working, but will not receive fixes. Download the current app from Settings.” Says what stops, what does not, and where to go.
7. Public API, Breaking change: “Version 3.0.0: GET /orders now returns 50 results per page instead of 100. Use the next link to fetch the rest.” The version number itself tells developers to read carefully.
8. Public API, Deprecated: “The customer_name field is deprecated and will be removed in 4.0.0. Use customer.display_name instead.” Names the replacement and the version it goes in.
9. Internal HR tool, New: “Managers can approve holiday requests from the email notification, without opening the tool.” Internal notes need the same care, because internal users also skim.
10. Any product, Security: “Fixed a security issue in password reset. No action is needed.” Enough to be honest, not enough to help an attacker before everyone has updated.

Release notes from a task board

The easiest release notes to write are the ones whose raw material is already sorted. On a fenbs board every task is a feature, an enhancement or a bug, which maps directly onto New, Improved and Fixed. When a task reaches Completed the board also records how it ended, and only Completed counts as delivered; tasks closed as Won’t fix, Duplicate, Cannot reproduce or Obsolete stay out of the notes. Each task carries a test status and test notes, so anything marked Not tested is a question to answer before it is announced. The task’s note says what was wrong or wanted, in the words of whoever asked, which is usually closer to a release note than a commit message ever is.

If an AI assistant is connected to the board, it can draft the notes from the Completed tasks and a person checks each line against its task before anything is published. That method, with the prompt and what to leave out, is in AI release notes from finished tasks. If you share a roadmap with invited clients, the product roadmap template uses the Completed lane as the changelog.