← Changelog

Release notes template, free, in Markdown and plain text

Here is the whole release notes template. Copy what you need from the block below, or take the file, and there is no form in front of either.

## 2.4

Released 9 September 2026.

One or two sentences saying why this release matters, written for
somebody who does not know your internal vocabulary.

### Breaking changes

- The v2 API stops accepting requests on 1 November. Move to v3,
  which takes the same fields.

### New features

- Search the board by heading, tag or the name of the person who asked.
- Export your voters and what they pay as a CSV.

### Improvements

- The board loads in about half the time on projects with more than
  a thousand requests.

### Bug fixes

- The vote count no longer drifts after two requests are merged.

### Security

- Session tokens are rotated when a password or email address changes.

Take the file, with the guidance notes still in it. It is Markdown, it is under three kilobytes, and it may be copied, changed and used commercially with no attribution and no link back. If it is useful, use it.

What goes in a release note that people read?

The order, more than the wording. Everything else on this page is preference and this part is not.

Breaking changes first. Somebody opening a release note is asking what is about to stop working. Answering that in the last section means answering it after they have closed the tab. If nothing breaks, delete the heading rather than writing none under it.

Then what is new, then what got better, then what got fixed. That is descending order of how likely a reader is to care, and it lets somebody stop reading at any point without missing something that affects them.

Security gets its own heading even when it is one line. Buried in a list of fixes it reads as routine. On its own it reads as something you take seriously, which is the impression you actually want and, if you did the work, the accurate one. Say what you changed and never describe the exploit.

One line per item, written from the reader's side. Not the name of the module. What a person can now do that they could not do yesterday. If an item needs a paragraph it wants its own post, and the note should link to it instead.

If you want to see the output on a real board rather than in a text box, the demo is open without an account.

Does this work for a shipped build as well as a web application?

Yes. A release note has the same job whatever ships, which is to tell somebody what changed and whether they have to do anything about it.

What a bigger project usually adds is a second audience. The same release often needs a customer facing note and an internal one with the migration steps and the rollback. Write the customer one from this template and keep the internal one wherever your runbooks live, because a note that tries to be both gets read by neither.

Is there a Word version?

No. The file above is plain text, so it pastes into Word, Google Docs, Notion, a pull request or an issue tracker exactly as it appears, and the headings survive the paste in all of them.

Why do teams stop writing these?

Not because of the template. Formatting a note takes a few minutes. Writing one every time you ship is what stops, usually a month or two after somebody decides the team should have a changelog.

The fix is structural: make the entry out of work you already tracked, so there is no second list to keep in sync. If you want a draft assembled for you instead of a file to fill in, the generator does that as you type.

Related reading

Changelog generator, in the five categories that scan Changelog vs release notes, and which one you owe a customer A changelog that emails the people who asked for it