Release notes templates you can copy and paste

A template is worth having for one reason: it removes the blank page, so the note gets written before the release rather than the Friday after. Here are six. Copy one, replace the brackets, delete what does not apply.

If you are starting from a commit log, the free Release Notes Generator will sort it into New, Improved and Fixed first.

1. The standard entry

Use it for almost everything.

## [What someone can now do, as a sentence]

[New | Improved | Fixed] · [Date]

[One sentence: what changed.]

[One sentence: why, or what it replaces.]

[Optional: where to find it, or a link to the docs.]

Filled in:

## Export any report to CSV

New · 22 September 2026

Every report now has an Export button that downloads exactly what is on
screen, filters included.

Until now the only export was the full monthly file, which meant
filtering it again in a spreadsheet. You will find the button at the top
right of any report.

2. The bug fix

State the problem the way the customer saw it, then that it is fixed. No apology paragraph; a plain fix is more reassuring.

## Fixed: [the problem, as the customer experienced it]

Fixed · [Date]

[What was going wrong, and for whom.]

[It is fixed as of this release. Anything the reader needs to do, or
"No action needed."]

3. The weekly roundup

For teams that ship many small things. One entry a week beats twelve entries nobody reads.

## This week: [the biggest change], and [n] smaller improvements

[Date]

**New**
- [Change, as a sentence]

**Improved**
- [Change]
- [Change]

**Fixed**
- [Problem that no longer happens]
- [Problem that no longer happens]

4. The breaking change

The one kind of note people must read. Say what breaks, when, and exactly what to do, in that order.

## [What is changing], on [date it takes effect]

Improved · [Date published]

**What is changing:** [one sentence.]

**Who is affected:** [who, and how they can tell.]

**What to do:** [numbered steps, or "Nothing, if you …"]

**If you do nothing:** [what happens on the date.]

[Link to the migration guide. A way to reach you with questions.]

5. The product update email

The changelog entry, shortened. One email per release is easier to keep up than a monthly digest, and arrives while the change is still news.

Subject: [What someone can now do]

[First name, or no greeting at all],

[One sentence: what changed.]

[One sentence: why it matters, or what it replaces.]

Read the full note: [link to the entry's own page]

— [Your name], [Product]

You are getting this because you subscribed to [Product]'s changelog.
Unsubscribe: [link]

6. A Keep a Changelog section

For the CHANGELOG.md in your repository, in the Keep a Changelog format. The free CHANGELOG.md Validator checks a file against it.

## [1.4.0] - 2026-09-22

### Added
- [New capability]

### Changed
- [Behaviour that is different now]

### Fixed
- [Bug that no longer happens]

### Removed
- [Anything taken away, and what to use instead]

Using them well

• Write the title last. Once the two sentences exist, the title is usually sitting in the first one.
• Titles are sentences. "Dark mode" is a label. "Dark mode, and it follows your system setting" is a release note.
• Cut what a customer cannot see. Refactors and dependency bumps belong in the repository file.
• Keep the shape the same every time. Readers learn where to look.

How to write release notes people actually read has the longer version of each of those.