Your changelog tells your users what shipped. The entries you publish appear on your portal's Changelog and in your widget's What's new, and can be emailed to the people who subscribed. Anyone on your team can write and publish them.
Find your entries
Open Changelog in the sidebar. Entries are in two tabs:
Drafts: entries only your team sees, the most recently edited first.
Published: entries on your portal, newest first, each with its date, how many posts it completes and its reactions.
Write an entry
Choose New entry.
Give it a title: what shipped, in a few words.
Under the title, write what changed. Type
/for headings, lists, quotes, code blocks, dividers, images and videos (YouTube, Vimeo or Loom).Choose Save draft. Only your team sees it until you publish it. From then on the button is Save.
The sidebar beside the text sets the rest:
Tags: New, Improved, Fixed and Breaking; pick any of them. Readers can filter the changelog by them, and Breaking shows in red.
Posts it completes: choose Link post… and pick a planned, in-progress or completed post that this entry ships. Remove one with its ×. On your portal the entry links to them under Completes.
Cover image: shown with the entry on your portal, in the widget's What's new and in the email to subscribers.
How it's announced: what happens when you publish (below). It shows once the entry is saved.
On your portal: View as reader opens the entry on your portal once it's published.
To have AI write or rework the text, see Draft release notes with AI.
Publish an entry
Save your changes.
Under How it's announced, choose:
Email subscribers: emails the entry to the people who subscribed to your changelog. See Email your changelog to subscribers.
Mark it new: every published entry is in your widget's What's new. Marked new, readers also see that it's new until they've looked (see What readers see, below).
Both are ticked to start with.
Choose Publish. Tuti says what will happen, for example that it's emailed to your subscribers and that the posts it completes become Completed. Choose Publish again.
When it's published:
the posts it completes become Completed, and the people who wrote, voted on, commented on or follow them get an email that it shipped;
How it's announced says what happened: whether it was emailed and marked new, and Told N people who asked: everyone it emailed, the people behind its posts and your subscribers together, each address once.
If the text is still only the pull requests' titles, Publish asks Publish the pull requests' titles? first, with Publish anyway and, unless you're out of AI credits, Draft with AI.
Change, unpublish or delete an entry
Change it: edit a published entry and choose Save. Your portal shows the new version. Emails already sent stay as they were.
Change the posts it completes: a published entry's posts are fixed, because publishing completed them. Unpublish it first.
Unpublish: takes it off your portal and back to Drafts. Its posts keep their status. Publishing it again doesn't email subscribers who already got it.
Delete: choose More actions (⋯) in the top bar, then Delete, and confirm. It's removed from your portal's changelog, and its posts keep their status.
Next release: the running draft
With GitHub connected, each pull request merged in your repositories goes into a draft called Next release, marked Collecting pull requests, as a line that links to it. Once that draft has a pull request in it, and after a release closes it until you publish it, Changelog shows Next release is ready to write, and Write it opens it.
With Autopilot on, Autopilot takes out the pull requests your users wouldn't notice and rewrites each remaining line in your users' words. See Set up Autopilot.
With Autopilot off, every merged pull request goes in, except those labelled
chore,internal,depsordependencieson GitHub.A release published on GitHub closes the draft and names it after the release, unless you've renamed it. The next merge starts a new Next release. Publishing the draft yourself closes it too.
Write it up by hand or with Draft with AI, then publish it like any other entry.
What readers see
Your portal's Changelog lists published entries, newest first, 20 to a page; Older entries and Newer entries move between pages. Each entry shows its date, tags, title, cover image, text and the posts it completes, and its title opens a page of its own. On wide screens the date sits in a margin to the left.
Tag chips: under the heading, All and a chip for each tag that at least one published entry has. A chip shows only the entries with that tag. The page's address keeps it, so readers can share the filtered view.
Months: on wide screens, once there are 9 or more entries (counting only the chip's, if one is picked), a Months list beside the changelog gives each month and its number of entries. Choosing a month jumps to it. On phones, the menu in the portal's header lists the latest entries by date instead.
RSS: the RSS button is a feed of your latest 50 entries, for feed readers.
Reactions: signed-in readers can react with 👍, ❤️ or 🎉. Signed out, they see the counts.
Get updates by email: on a public portal, readers can subscribe. See Email your changelog to subscribers.
New: for an entry published with Mark it new in the last 30 days, signed-in readers see New on the portal's Changelog tab until they've seen it. In the widget, Home's What's new card says how many entries are new and opens the 10 latest, each new one with a dot. See Customize the widget's button and Home.
Entries from Add sample content are labelled Sample: they're never marked new or emailed, and the RSS feed leaves them out.