You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A first cut of a release notes page at /release-notes, so people can see what changed in a release without going to the GitHub releases tab. The old "Release notes" link sent you to GitHub; this turns it into a real page, reachable from the side menu and search.
It's a mock to react to, not the finished thing. There are a few hand-written entries (a recent release, an older one with a breaking change, and a small patch) so we can see how it reads at different sizes. It doesn't pull from our actual releases yet.
How it reads
Releases are grouped by month, with a month list on the right to jump around. Each change is a short title and a detail, rather than sorted into fixed buckets like fixes vs features. Component names link to their component pages, and a feature can link to its docs (dark mode links to the designer and developer guides). Affected package versions show as small badges.
A couple of things get a light callout: experimental features like dark mode, and breaking changes with a before/after. I kept those rare so they still stand out.
It's all built from our own goa components.
On the direction
I started from the fixes / features / breaking grouping we'd talked about, but looking at how Claude and Notion do their changelogs, it moved to this title-and-detail style. Curious whether that reads better. Dustin, the grouping was your call originally, so keen for your take.
How to look
Open the deploy preview and go to /release-notes.
Not here yet (on purpose)
Connecting it to our real releases, backfilling the history, paging through older releases once there are more of them (load more), the MCP, and RSS. Those are follow-ups. The page shows written content by design, so connecting later is incremental, not a rebuild.
Thanks for putting this up @twjeffery. I think this is looking good overall! It will be great to have this on the website 🙌
not specifically related to this PR but I have felt for a long time that when we use the tag on our DS website it doesn't really look that great, I did a bit of poking around and it looks like we can do some formatting that might make things look a bit better on the page.
I noticed that we have a number of "rn" classes for various elements on this page. Do we need these?
I wonder if the package version numbers that we have listed above the release heading should be links to the different NPM packages
For the release view I noticed that we are moving away from the "Bug fixes" and "New additions" headings. Regardless of the specific names I think headings to separate the different parts of the release are helpful to organizing things.
twjeffery
changed the title
Add release notes page
feat(#3904): Add release notes page
May 29, 2026
Thanks for putting this up @twjeffery. I think this is looking good overall! It will be great to have this on the website 🙌
not specifically related to this PR but I have felt for a long time that when we use the tag on our DS website it doesn't really look that great, I did a bit of [poking around](https://css-tricks.com/styling-code-in-and-out-of-blocks/) and it looks like we can do some formatting that might make things look a bit better on the page. * I noticed that we have a number of "rn" classes for various elements on this page. Do we need these? * I wonder if the package version numbers that we have listed above the release heading should be links to the different NPM packages * For the release view I noticed that we are moving away from the "Bug fixes" and "New additions" headings. Regardless of the specific names I think headings to separate the different parts of the release are helpful to organizing things.
Thanks @Spark450, I pushed an update that covers most of these:
<code> styling: agreed it could look better, and the CSS-Tricks link is a good starting point. Since it's site-wide and not specific to this page, I'll track it as a separate follow-up rather than roll it into this PR.
The rn classes: fair to flag, that was a cryptic abbreviation. I renamed them to release-notes-* to match how the rest of the site scopes its classes (tokens-*, components-*). The ones that remain are doing layout for the feed, where there isn't a component to use instead.
Version numbers as npm links: done. They now link to each package's version page on npm.
Section headings within each release: agreed, brought them back. Changes are grouped under headings again (Breaking changes, New additions, Feature changes, Bug fixes, Design system website) so each release is organized into sections.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
twjeffery
force-pushed
the
tom/release-notes-page
branch
from
Spark450
left a comment
What this is
A first cut of a release notes page at /release-notes, so people can see what changed in a release without going to the GitHub releases tab. The old "Release notes" link sent you to GitHub; this turns it into a real page, reachable from the side menu and search.
It's a mock to react to, not the finished thing. There are a few hand-written entries (a recent release, an older one with a breaking change, and a small patch) so we can see how it reads at different sizes. It doesn't pull from our actual releases yet.
How it reads
Releases are grouped by month, with a month list on the right to jump around. Each change is a short title and a detail, rather than sorted into fixed buckets like fixes vs features. Component names link to their component pages, and a feature can link to its docs (dark mode links to the designer and developer guides). Affected package versions show as small badges.
A couple of things get a light callout: experimental features like dark mode, and breaking changes with a before/after. I kept those rare so they still stand out.
It's all built from our own goa components.
On the direction
I started from the fixes / features / breaking grouping we'd talked about, but looking at how Claude and Notion do their changelogs, it moved to this title-and-detail style. Curious whether that reads better. Dustin, the grouping was your call originally, so keen for your take.
How to look
Open the deploy preview and go to /release-notes.
Not here yet (on purpose)
Connecting it to our real releases, backfilling the history, paging through older releases once there are more of them (load more), the MCP, and RSS. Those are follow-ups. The page shows written content by design, so connecting later is incremental, not a rebuild.
Addresses #3904 and #3797.