Release notes people can scan

Release notes should explain what changed for the people using a product. Start with the version and release date. Group the changes into additions, improvements, fixes and known limitations. Keep each item specific enough that a reader can identify whether it affects their work. Internal ticket names alone rarely provide that context. Describe the outcome before the implementation detail. For example, say that exports now preserve column order before mentioning a serialization change. Do not claim that all problems are fixed when only a particular case was addressed. Link to existing product documentation for longer explanations rather than copying it into every release. Give breaking changes their own section. State what users must do, when they must do it and where they can find the supported procedure. Separate a required migration from an optional new setting. Never include private credentials or customer-specific examples in publicly shared release notes. Keep known limitations visible. If a feature is limited to a particular platform or rollout group, say so plainly. Avoid listing work that has not actually shipped. Draft notes can be prepared early, but publication should match the released version. After checking the notes with the release owner, share a stable version. Use a copy for the next release instead of replacing text under a link that others may already be using. Long-term documentation belongs in the official product history; a paste is useful for a short-lived announcement or review draft.

Version: [version]
Released: [date]

Added
- [user-visible capability]

Improved
- [improvement]

Fixed
- [specific issue]

Action required
- [migration or none]

Known limitations
- [limitation]

Documentation
[official documentation reference]