
Release notes are the customer-facing record of what changed in a software release—new features, improvements, fixes, and known issues—written so people can understand the change and what to do next. They sit between the engineering changelog and marketing launch copy: more outcome-focused than a commit log, more precise than a blog post.
For product teams, release notes are how transparency becomes operational. One dated entry, written once, can feed email, in-app surfaces, and internal briefs without reinventing the facts each time.
Small releases might need only a date and one line. A complete note, with a worked example, is in how to write release notes.
| Type | What it's for | Typical reader | Go deeper |
|---|---|---|---|
| Major release / launch note | A significant new capability, often with a launch around it | Customers and prospects | Templates |
| Improvement digest | A roundup of smaller enhancements on a regular schedule | Active users | How to write |
| Bug fix note | What was broken, who was affected, what is fixed | Affected users, support | Templates |
| Breaking change or deprecation notice | Something is being removed or changed in a way that needs action | Admins, developers | Breaking changes |
| Internal release note | Context for sales, support, and CS before customers see the change | Internal teams | Internal release notes |
| App store "What's new" text | A short summary shown on the store listing | Mobile users | Google Play allows up to 500 characters per language; Apple's App Store allows up to 4,000 |
A changelog is a related record rather than a type of release note. It is the complete, often technical list of changes, and release notes are usually drawn from it. See release notes vs. changelog.
Release notes have more than one audience. End users want to know what's different, admins want to know what they need to configure, developers want exact API and version details, and internal teams (support, sales, success) need to know before customers ask. Good teams write one accurate record and adapt it for each group (release notes for different audiences).
The record usually lives on a public release notes or changelog page. From there it goes out through email, in-app announcements, and internal channels depending on how much the change matters (multi-channel distribution, in-app patterns).
Schedule reports to Slack
September 15 · All paid plansYou can now send any saved report to a Slack channel on a daily or weekly schedule.Set it up from the report's Share menu.Fixed: CSV exports no longer drop the last row on large reports.For real-world pages from companies like Stripe, Linear, and Notion, see release notes examples.
Every guide in the hub, grouped by what you're trying to do.
A short, dated explanation of what changed in a release, written for the people who use or support the product—not a dump of every commit.
A changelog is the technical record of changes; release notes explain impact and next steps for readers. Full comparison → Release Notes vs. Changelog. Changelog definition → What Is a Changelog?.
On most SaaS teams, product or product marketing drafts; engineering reviews facts; support or CS reviews customer impact; one person owns publish. Ownership model → Who Writes Release Notes?.
Publish whenever there is a change a reader would notice or need to act on. For teams that ship continuously, that usually means a note for each meaningful change plus a regular (weekly or monthly) digest of smaller improvements and fixes. Consistency matters more than frequency: readers come back to a page they trust will stay current. Channel cadence is covered in best practices.
Read how to write for craft, skim one template, and pick a single owner for the next release in who writes.
The job of this hub is education first: clear definitions, practical guides, and honest ownership models. LaunchNotes is built for teams that want one publishable record behind every surface. Worth a look if your notes still live in a doc that never reaches customers.