Changelog examples worth stealing from
Seven public changelogs and release notes, each good at one specific thing. I read a lot of these while figuring out my own, so you don’t have to. No ranking, no “15 best tools”, just the habit to take from each.
Example
Linear
The changelog people mean when they say a changelog can be marketing. Regular entries, a screenshot or clip for anything visual, and features that get named like products instead of ticket numbers. It reads like the team is proud of the work, because they are.
Steal this: Give a feature a name and a picture. A screenshot does more than three paragraphs.
Example
Stripe
The grown-up end of the genre. API changes are dated, versioned and specific about who is affected, and breaking changes come with what to do about it. Nobody reads it for fun, and nobody who depends on it would trade it for fun.
Steal this: When a change breaks something, say who it breaks and what the migration is, in the entry itself.
Example
VS Code
Monthly release notes at a scale that should be unreadable and somehow is not, because everything is grouped by the part of the product it touches. You skim to your section, read three entries, and leave informed.
Steal this: Group by product area, not by chronology or by team, so a reader can skip to the part they use.
Example
GitHub
The high-volume counterexample to writing essays. Entries are a few sentences, labeled by product, published as they ship rather than saved up for a launch post. It works because each entry is one change, stated plainly.
Steal this: One change per entry. Small entries, often, beat big entries, sometimes.
Example
Tailwind CSS
Release posts where the release notes are half code. Every feature is demonstrated in the utility classes you would actually type, so reading the announcement is also learning the feature.
Steal this: If your product is code, show the code. An example is worth more than the adjective in front of it.
Example
Keep a Changelog
Not a product changelog but the reference format most good CHANGELOG.md files use, and the site maintains its own changelog in its own format, which is the right kind of showing off. Categories, versions, dates, reverse chronological order.
Steal this: Adopt a boring standard instead of inventing a clever one. See the format guide below for the details.
Example
Merge & Tell (mine)
Included with appropriate embarrassment, since grading your own homework is bad form. It is smaller than everything above. The one thing it does that the others do not: every entry starts life as a draft written from a real merged pull request, by the tool this site sells, and I approve each one before it goes out. I use it daily, which is the only endorsement I can offer honestly.
Steal this: Publish the entry when the work merges, while you still remember why the work mattered.
The common thread
What the good ones share
None of these are good because of the design. They are good because entries describe changes a user can feel, they show up on a rhythm you can set a watch by, and someone clearly decided what was not worth including. Consistency beats cleverness, which is annoying, because cleverness is more fun to write.
If you want the structure these examples hang off, the changelog format guide covers it, and the release notes template is the copy-paste version. The part none of those fix is sitting down to write the entry every single release. That part I automated, because I lost to it for years.
Your changelog could be an example.
You were going to merge the PR anyway.