---
title: Release notes templates you can copy and paste
description: Six release notes templates to copy — a standard entry, a bug fix, a weekly roundup, a breaking change, a product update email and a Keep a Changelog section — with when to use each.
canonical: https://relnotely.com/blog/release-notes-templates
published: 2026-09-22
updated: 2026-09-22
---

# Release notes templates you can copy and paste

Six templates, each short enough to fill in before the release goes out. Copy one, replace the brackets, delete what does not apply.

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](/tools/release-notes-generator) will sort it into New, Improved and Fixed first.

## 1. The standard entry

Use it for almost everything.

```markdown
## [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:

```markdown
## 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.

```markdown
## 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.

```markdown
## 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.

```markdown
## [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.

```text
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](https://keepachangelog.com) format. The free [CHANGELOG.md Validator](/tools/changelog-md-validator) checks a file against it.

```markdown
## [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](/blog/how-to-write-release-notes) has the longer version of each of those.

## Questions

**What should a release notes template include?**

A title that says what changed, the date, what kind of change it is — new, improved or fixed — one or two sentences on what it means for the reader, and a link if there is more to know. Anything beyond that is optional.

**How long should release notes be?**

A title and two or three sentences for most changes. A breaking change or a large launch can run longer, but the first two lines should still say everything a skimming reader needs.

**Should I use the same template every time?**

Use the same shape every time, so readers know where to look. The standard entry covers most releases; reach for the others when the release is a fix, a roundup, a breaking change or an email.

**Can I generate release notes from my commits?**

As a first draft, yes. The free Release Notes Generator on this site groups commit messages into New, Improved and Fixed and drops internal work. The titles still need rewriting for customers, which is the part no generator does well.

---

Published by Relnotely at https://relnotely.com/blog/release-notes-templates