Release Notes Template

About this template

Written for the person who has to do something

A release note is not a changelog. It is read by someone deciding whether to upgrade now, and by someone who will be woken up if the release goes wrong. The label above the title reads Release notes, and the gray line under the title reads “Complete it in order, from Summary of this release through Support and follow-up.” Unlike the other forms in this set, this one has no approval block – it ends at the Key metrics table, because a release note is published rather than signed off.

Filling order

1. Fill the four information cells: Version, Release date, Rollout scope and Release owner. They ship as v2.7.0, 2026-06-11, All web and mobile, and Platform Engineering Team. Rollout scope is the cell readers check first, so say plainly whether this reaches everyone or a subset.
2. 1. Summary of this release is written last but printed first. Draft it once the change list is settled.
3. 2. Change list is where the work goes, split three ways rather than merged.
4. 3. Compatibility and known issues collects everything that has to be caught before you ship.
5. Fill the Key metrics table with this release’s numbers.

How the three sections read

• Summary of this release. “Tell the reader in the first paragraph what they have to do now.” Version, release time and expected downtime; the one change nobody can afford to miss; and which users are affected. If a reader stops after this section they should still know whether the release touches them.
• Change list. Keep new features, improvements and fixes in separate lists. Give each new feature one line on how to use it, say what changed and how for improvements, and write fixes by symptom with the issue number alongside. Symptom-first matters because the person searching this note is searching for what they saw, not for what you changed.
• Compatibility and known issues. What is being retired and what replaces it, whether data migration or configuration changes are needed, and workarounds for open issues together with the rollback procedure. Publishing known issues costs nothing next to a support queue full of the same question.

The four metric cells

Key metrics is a two-row, four-column table with values on top: v2.7.0 / This version, 14 / New & improved, 23 / Bug fixes, 0 min / Downtime. The counts should match the number of entries in section 2, and Word will not reconcile them for you, so recount after the last edit. Downtime is the cell readers use to plan around you: quote the window you will actually hold rather than an optimistic one, and if it is genuinely zero, say what makes it zero – a rolling deploy, a feature flag – in the summary.

Support and follow-up

The gray lead runs through to support and follow-up, and that is the part most releases drop. Name where questions go and how quickly they will be answered, and keep the rollback procedure written down rather than held by one person. Publish the note at the same time as the release, not after; a note that arrives an hour later is read as an apology. For a version people can skip, say which release they can go straight to and which ones they cannot skip past, because the reader with three versions to catch up on is the one most likely to break something.

Before you publish

• Merging fixes into the feature list, which hides the change that actually matters.
• Writing fixes by cause rather than by symptom, so nobody can find them.
• Counts in the metrics table that no longer match section 2.
• Naming a deprecation with no replacement and no date.
• Leaving v2.7.0 and the sample date in place. Those two cells are how support ties a report back to a build.