Software release notes template: customer-facing product updates from verified changes
A copy-paste software release notes structure for a verified release summary, new features, improvements, fixes, known limitations, audience impact, required actions and supporting links.
No email gate. Copy the Markdown into your changelog, product update doc or release-prep workflow. The structure is customer-facing; the existing ShipStory approval template remains the separate control for source evidence, claim permission and reviewer sign-off.
Copy-paste format
Translate shipped evidence into user language.
Keep internal commit details in the evidence trail. Publish only the behavior, impact, limitation or action that the release actually supports.
# [Release name / version] — [actual release date] ## Summary [One sentence describing the most important verified customer-facing change.] ## New - [Feature]: [What users can now do and who can access it.] ## Improved - [Area]: [Observable improvement. Do not invent a metric that was not measured.] ## Fixed - [User-visible problem]: [What now behaves differently.] ## Known limitations / rollout - [Availability, rollout, unsupported path, limitation or remaining issue.] ## Action required - [Migration, configuration or user action — omit when none is required.] ## Learn more - [Help / migration / product link]
Release-note QA
Every line needs a released fact behind it.
- [ ] Release name or version and the actual release date recorded - [ ] One-sentence summary states the verified customer-facing change without unsupported benefit claims - [ ] New features list only behavior that is present in the released product - [ ] Improvements describe observable changes without inventing performance metrics or adoption outcomes - [ ] Fixes describe user-relevant resolved behavior without dumping internal ticket or commit language - [ ] Known limitations and rollout or availability boundaries remain visible where they affect users - [ ] Required user action, migration step or breaking-change instruction is explicit when evidence supports it - [ ] Help, migration or product links point to current destinations rather than placeholder documentation - [ ] Source release evidence and the customer-facing draft stay linked for reviewer verification - [ ] Human reviewer confirms claim permission and audience suitability before publication
Release name or version and the actual release date recorded
One-sentence summary states the verified customer-facing change without unsupported benefit claims
New features list only behavior that is present in the released product
Improvements describe observable changes without inventing performance metrics or adoption outcomes
Fixes describe user-relevant resolved behavior without dumping internal ticket or commit language
Known limitations and rollout or availability boundaries remain visible where they affect users
Required user action, migration step or breaking-change instruction is explicit when evidence supports it
Help, migration or product links point to current destinations rather than placeholder documentation
Source release evidence and the customer-facing draft stay linked for reviewer verification
Human reviewer confirms claim permission and audience suitability before publication
A merged PR is evidence of code change, not proof of every customer benefit.
Do not turn an internal implementation description into an unsupported performance, security, reliability or adoption claim. If a benefit was not measured, phrase the released behavior rather than inventing the outcome.
Keep known limitations and rollout boundaries visible. A cleaner release note is not one that hides the parts a customer needs to make a safe decision.