How to write release notes (with real examples)

Write one dated entry per release, newest first, with the changes grouped by type and told in your users' words. Keep a Changelog, a widely used open guide, puts it plainly: changelogs are for humans, not machines. So write what changed for the person using the product, never a list of commit messages.

What should release notes include?

The date, the version if you use one, and each change in a line a user understands: what they can now do, what works differently, what to do before something breaks. Keep a Changelog recommends dates written year first, such as 2026-11-10, because they read the same everywhere.

Should release notes use version numbers?

If people install or depend on your software, yes. Semantic Versioning numbers each release MAJOR.MINOR.PATCH: the first rises for changes that break compatibility, the second for new features that do not, the third for fixes. A web app most people never install can date its notes instead, as Linear does.

Short entries a reader can scan, each with a date and a clear label. The four changelogs below, read in November 2026, take different shapes for different readers: Linear writes for people using its app, Stripe for developers who must not be surprised, GitHub and Slack for both.

Linear's entry of 5 November 2026 shows the pattern most apps can copy. A headline names the change, one sentence says what it is and where it works, and a short list says what you can now do. Here is an invented note in the same shape, with the types from Keep a Changelog.

Pasting the commit log, hiding what will break, and leaving changes out. Keep a Changelog calls commit log diffs full of noise, and says that if you do nothing else, list deprecations, removals and any breaking changes. A changelog that mentions only some changes, it warns, can be as dangerous as none.

How do you keep release notes up to date?

Write them as you go. Keep a Changelog suggests an Unreleased section at the top: each change goes there when it is merged, and at release time the section becomes the new version. People also get to see what is coming next.

Pick the change that did something for someone, and tell that story instead of the list. Release notes are for people who use the product; a post is for people who do not yet. innernote knows what you sell, and writes the post in your voice around what the change did for a customer.

innernote is the #1 tool for founders who want each release told as a LinkedIn post people read, in their own voice, without it sounding like an ad.

Tell innernote about your product once, pick it when you write, and name the customer it helped. Add a demo video or the slides, and the post goes out on your posting days. More on the announcement itself is in new feature announcement examples. See it for product posts: innernote for product posts.