Skip to content

Release Notes Template (Markdown)

A release notes template in plain Markdown for software teams. It leads with what changed for the reader, separates new, improved and fixed, and gives breaking changes and upgrade steps their own section so nobody finds them by accident. Copy it, download the .md file, or keep it in your repository as CHANGELOG.md or one file per release.

Free to use, no attribution required (CC0).

Open in Folio demo

{{Product name}} {{X.Y.Z}}

Released: {{YYYY-MM-DD}} Type: {{Major / Minor / Patch}}

One or two sentences: why should a user care about this release?

{{Summary: the main thing this release does for the reader.}}

Highlights

  • {{Headline feature}} — {{one line on what the reader can now do}}. Docs
  • {{Second highlight}} — {{...}}

New

Written from the reader's side. Link to docs, issue or pull request.

  • {{You can now ...}} (#{{123}})
  • {{...}}

Improved

  • {{... is now faster / clearer / more flexible}} (#{{124}})

Fixed

  • {{Fixed an issue where ... when ...}} (#{{125}})

Breaking changes

Delete this section only if there are none. Say who is affected, what to change, show before and after.

  • {{What changed}}. Affects: {{who}}. Before:
    {{old behaviour, command or config}}
    
    After:
    {{new behaviour, command or config}}
    

Deprecations

  • {{Feature}} is deprecated and will be removed in {{version or date}}. Use {{replacement}} instead.

Security

  • {{Fixed ... (affects versions A–B, fixed in this release)}} (advisory)

Upgrade steps

  1. {{Back up ...}}
  2. {{Update to X.Y.Z with ...}}
  3. {{Run the migration ...}}
  4. {{Verify with ...}}

Known issues

  • {{Issue}} — workaround: {{...}} (#{{126}})

Thanks

{{Contributors and reporters, by name or handle.}}

Full changelog: {{link to compare view or CHANGELOG.md}}

Want to see it as a real wiki page? Open this template in the Folio demo, where it is a normal Markdown page.

How to use it

  1. Step 1: Copy the template and fill in the header. Version, date, and a one-sentence summary of why anyone should care about this release.

  2. Step 2: Write each change from the reader's side. Describe what a person can do now or what stops being broken, not which function you refactored. Delete empty sections.

  3. Step 3: Put breaking changes and upgrade steps where they cannot be missed. Then publish the page, and link it from the release tag, the announcement and the in-product update message.

What makes good release notes

They start with the effect on the reader. "You can now export a page to PDF" beats "Added PDF export module". Group by what the reader does (new, improved, fixed), not by which team did the work.

Breaking changes are impossible to miss. Give them a dedicated section with who is affected, what to change, and a before/after example. The cost of burying one is paid in support tickets.

Every entry is linkable. A short link to the issue, pull request or documentation lets a curious reader dig deeper without making the notes long.

They are written once for humans, not generated and forgotten. Commit messages are a good input and a bad output. Edit the list, merge duplicates, and keep one voice.

Questions

What is the difference between release notes and a changelog?
A changelog is a complete, chronological list of changes for developers, often kept in CHANGELOG.md. Release notes are the edited, reader-friendly version for a specific release. Small projects often use one document for both.
What should release notes include?
Version and date, a short summary, new features, improvements, bug fixes, breaking changes with upgrade steps, deprecations, and known issues. Skip any section that is empty.
How often should I publish release notes?
With every release that a user can notice. For continuous deployment, publish a weekly or monthly roll-up and keep fine-grained entries in the changelog.
Should release notes mention security fixes?
Yes, in a clearly marked entry, with the affected versions and the fixed version. Give enough detail for users to decide to upgrade without publishing a recipe for exploiting the flaw before they can.
Where should release notes live?
Next to the code in the repository, so the notes for a version are tied to its tag, and on a public page for users. In a wiki, a page per version keeps the history searchable and linkable.

Updated 11 October 2026.

Release notes as versioned pages next to your docs

In Folio each release is a Markdown page in Git. Store the notes in the same repository as the code (several Folio spaces can point at different folders of one repository), keep the template in the space's template folder, and your team creates the next release's notes from the template.