A release notes template you can copy

A template won't make your release notes good, but it removes the two failure modes that kill most of them: staring at a blank page until the update doesn't ship, and a format that changes every release so readers never learn where to look.

Here is the template. Copy it, then read the filling rules below — they're where the quality comes from.

The template

## v2.14.0 — 8 March
 
**TL;DR:** One sentence on the single most important change in this release.
 
### New
 
- **Bulk CSV export.** You can now export any report over 10,000 rows
  as a CSV in one click. [Docs](https://example.com/docs/export)
- **Feature name.** What the user can do now, in one or two sentences.
  Link to docs if setup is needed.
 
### Improved
 
- **Dashboard load times.** Large accounts now load in under two
  seconds, down from eight.
 
### Fixed
 
- Fixed a bug where some users were signed out after 15 minutes
  instead of 24 hours.
- Fixed duplicate notifications on mobile when a thread was updated.
 
### Breaking changes
 
- The `/v1/reports` endpoint now paginates at 100 results.
  If you rely on unpaginated responses, see the
  [migration note](https://example.com/docs/migration).
 
---
 
Questions or feedback? Reply to this email / post in #product-updates.

Delete any section with nothing in it. An empty "Breaking changes" heading is noise; a present one is a commitment readers learn to trust.

Rules for filling it in

The TL;DR line is for the 90% who read nothing else. Write it last, after you know which change matters most. If you can't pick one, your release notes are covering too many unrelated things — split them.

Every entry leads with what the user can do, not what you did. "Refactored the export pipeline" is a changelog entry, not a release note; the distinction is covered in changelog vs. release notes. The bold phrase names the capability; the sentence after it states the benefit or the limit.

Fixed entries name the actual bug. The users who hit it are your most motivated readers. "Minor fixes and improvements" teaches everyone to stop reading.

One visual for the headline feature. A screenshot or short GIF above the New section, showing the feature in use. Not one per entry — one per release is sustainable, and sustainable beats thorough. For the habits beyond formatting, see how to write release notes people actually read.

Version and date, always. Even if your users never see version numbers, support will use them within a week. The new/improved/fixed grouping itself is the near-universal convention — ReleasePad's template collection and Appcues' examples roundup both build on the same three sections.

The stripped-down weekly variant

If you ship continuously and publish weekly, most weeks don't earn the full structure:

## Week of 8 March
 
- **Bulk CSV export** is live for all plans. [Docs](https://example.com/docs/export)
- Dashboards load faster on large accounts.
- Fixed duplicate mobile notifications.

Three to six bullets, bold only the new capabilities, no sections. Graduate an item to the full template when it has a breaking change or needs a visual.

Developer-facing products should keep a separate complete record alongside either variant — the keepachangelog.com format (Added / Changed / Deprecated / Removed / Fixed / Security) is the standard there.

Filling the template is the easy half

The template tells you how to say it. Knowing what shipped and who cares still means someone assembling merged PRs and remembering which customers asked for each item — the part that erodes first under deadline pressure.

We build Modem for exactly that assembly step, so discount our enthusiasm accordingly: it captures feature requests from Slack, Discord, and support tools with the requester attached, matches merged PRs back to those requests, and drafts release notes where each entry already knows who asked for it. That matching runs on a context graph linking people to topics across channels, so a customer who asked in both email and Slack shows up once, with one follow-up. If your release notes are for an anonymous public audience rather than identifiable customers, that matching step mostly doesn't apply and the template alone is enough.

Start this week

Copy the weekly variant into wherever you announce updates. Fill in three bullets from what merged this week — capability first, bug names included. Send it. The full template can wait for your next versioned release; the habit can't.