Changelog and Release Notes Templates to Copy

A changelog is the running record of what changed in your product, and release notes are the story of one release for the people who use it. Most teams need both, and most stall on the blank page. Below are five templates you can paste into a Markdown file or a changelog tool today: a full changelog, a customer release note, a small-fix entry, a monthly roundup and a "you asked, we shipped" note. Each one comes with a short note on what every section is for, and the first two include a filled-in Acme example.

A good changelog entry has a date or version, a one-line summary, and changes grouped under the same headings every time. The usual headings are Added, Changed, Fixed and Removed, and breaking changes are marked clearly. Release notes cover one release for customers: what changed, who gets it, whether they need to do anything, and how to use it. Write from the user's side and keep each item to one line. Put the most important change first, and link each entry to the feature request or bug report it answers, so the people who asked can see it shipped.

Changelog vs release notes: what's the difference?

	Changelog	Release notes
Scope	Every notable change, every version	One release
Audience	Anyone who wants the full record	Customers who want the highlights
Lifespan	Grows over time	Written once, when it ships
Tone	Plain and factual	Can tell a story, with screenshots
Where it lives	A CHANGELOG.md file or a /changelog page	A changelog entry, in-app card, email or blog post

Many teams write the changelog entry first and turn it into release notes for bigger launches.

Template 1: Markdown changelog (Keep a Changelog style)

This template follows the Keep a Changelog format and uses Semantic Versioning for version numbers. Paste it into a CHANGELOG.md file and fill in the brackets.

# Changelog

All notable changes to this project are documented in this file.

## [Unreleased]

### Added
- [A change you have finished but not released yet]

## [x.y.z] - YYYY-MM-DD

### Added
- [New features]

### Changed
- [Changes to existing features]

### Deprecated
- [Features that will be removed soon]

### Removed
- [Features that were removed]

### Fixed
- [Bug fixes]

### Security
- [Fixes for vulnerabilities]

Here is the same template filled in for one version. Acme is a made-up product, and every detail below is an example.

## [2.4.0] - 2026-10-20

### Added
- Saved views: save the filters on the Reports page and reopen them in one click.
- CSV export for any report.

### Changed
- **Breaking:** The reports API now returns dates in ISO 8601 format. Update any code that parses report dates before you upgrade.

### Fixed
- Reports showed the wrong day for people in time zones behind UTC.

• Put the newest version on top.
• Write dates as YYYY-MM-DD.
• Leave out headings that have no entries.
• Mark breaking changes clearly, and say what the reader needs to do.

Template 2: Customer release note

Use this for one release that customers will notice. Fill in the brackets, and write "No action needed" when that is true.

# [Title: the change, written for the customer]

[One sentence on what changed and why it helps.]

**Who gets it:** [Everyone, one role, or one customer group]

**Do you need to do anything?** [No action needed. Or the steps to take.]

| Before | Now |
| --- | --- |
| [How it worked] | [How it works now] |

## How to use it
1. [First step, naming where the feature lives]
2. [Second step]
3. [Optional third step]

## Known limits
- [What it does not do yet, said plainly]

Thanks to: [Title of the original request](link to the original request)

And an example for Acme, the made-up product again. Every detail is an example.

# Save your report filters as views

You can now save the filters on the Reports page as a named view and reopen it in one click.

**Who gets it:** Everyone

**Do you need to do anything?** No action needed.

| Before | Now |
| --- | --- |
| You set the same filters on the Reports page every time. | You save them once as a view and pick it from a list. |

## How to use it
1. Open Reports and set your filters.
2. Click Save view and give it a name.
3. Next time, pick the view from the Views list.

## Known limits
- Views are private to you. Sharing views is not available yet.

Thanks to: [Saved views for Reports](https://acme.example/requests/142)

• Write the title as the change the customer sees, not the name of the project behind it.
• The summary is one sentence. Readers who stop there should still know what changed.
• "Who gets it" and "Do you need to do anything?" answer two questions customers will have right away.
• Keep the Before / Now table to the rows that changed, and "How to use it" to two or three steps.
• Say what the feature does not do yet under "Known limits".
• Link the original request in the "Thanks to" line.

Template 3: Small fixes and improvements entry

For weeks without a headline feature, use a dated entry with Improved and Fixed groups and one line per item.

## Updates: [Month D, YYYY]

### Improved
- [What the user notices, in one line]
- [What the user notices, in one line]

### Fixed
- [What the user notices, in one line]
- [What the user notices, in one line]

Write each line as what the user notices ("Search results load faster on large boards"), not as the ticket title. Tip: bundle small fixes weekly instead of writing one entry per typo.

Template 4: Monthly product update

A roundup shape that works as a changelog entry and as a newsletter section.

# [Month YYYY] product update

[Two sentences: what this month was about and who it helps.]

## Biggest change
[Name of the change]

[Screenshot or short clip goes here]

[Two or three sentences on what changed and how to use it.]

## Also new
- [Item]
- [Item]
- [Item]

## Fixed
- [Item]
- [Item]

## Coming next
- [An item that is already on your public roadmap]

Use the month and year as the title, and put the one change most readers care about first. Keep "Also new" to three to five bullets. Under "Coming next", list only items that are already on your public roadmap.

Template 5: "You asked, we shipped" note

For a change that came from customer requests.

# [Title naming the request]

## You asked for...
[Quote or paraphrase the request. Leave out customer names unless they said it is fine.]

## What we built
[Two or three sentences on what shipped.]

## How to try it
[Where it lives, and the first step.]

Original request: [link to the request]

Tell us what's missing: [where to reply]

Name the request in the title so the people who asked recognize it. The people who voted are the readers most likely to try the change, so link the entry back to the request. "Tell us what's missing" invites the next round of feedback.

What to include in every changelog entry

• A date or version
• A one-line summary up front
• Consistent headings, in the same order
• User-facing wording, not commit messages or ticket IDs
• Breaking changes marked, with the action needed
• A screenshot or short clip for visible UI changes
• A link to the related request, doc or roadmap item
• Who it's available to, if not everyone

Common changelog mistakes

• Pasting commit messages ("fix: null check in svc") instead of what changed for the user.
• Changing the headings every release, so readers can't scan.
• Burying a breaking change in the middle of a list.
• Long gaps followed by one giant entry. A short entry every week or two reads better.
• Announcing a feature nobody can find. Always say where it lives.

Keeping your changelog tied to feedback

If your feature requests live on a feedback board, the changelog is where those requests get their answer. In Feedjolt, you write entries in Markdown, save them as drafts or schedule them, and link each one to the posts it resolves, so those posts can be marked Shipped. When a post moves to Shipped, you can promote it to a changelog entry with the title and link filled in. People who voted on a linked post see a small "new" badge, and anyone can follow the changelog over RSS. Feedjolt's AI flags likely duplicates for a person to review, and agents work the board over MCP with the permissions a person grants. MCP access depends on your plan.

Make release notes findable

A public changelog page with one URL per entry, a clear title and a date can show up in search when people look up your product's features.

FAQ

What should a changelog include?

A date or version for each entry, a short summary, and the changes grouped under the same headings every time, such as Added, Changed, Fixed and Removed. Mark breaking changes and say what users need to do. Write each item from the user's side, not as a commit message.

What's the difference between a changelog and release notes?

A changelog is the full, running record of notable changes across every version. Release notes cover one release and explain it to customers, often with screenshots and context. Many teams write the changelog first and build release notes from it.

How often should you update a changelog?

Whenever something users would notice ships. Big features get their own entry. Small fixes can be bundled into a weekly or monthly entry so the page stays readable.

Should a changelog use version numbers or dates?

Use whichever your users already see in your product. Libraries and APIs usually use semantic versions. Most SaaS apps ship continuously and use dates. If you use both, put the date on every entry.

Is there a standard changelog format?

The most common one is Keep a Changelog: newest version first, ISO dates, and the headings Added, Changed, Deprecated, Removed, Fixed and Security. It pairs well with Semantic Versioning.

Who should write release notes?

Whoever can explain the change in plain words, often the PM or the engineer who built it, with someone else reading it once before it goes out.

Want your changelog and feedback board in one place? See Feedjolt.