Before submitting
Area
apps/desktop (also touches apps/web and packages/contracts)
Problem or use case
Related to #2309 ("Provide Release notes via Toast when new version is released in Desktop App"). This is a much smaller, tighter-scoped take on the same underlying need: instead of a post-update toast/page, it surfaces the changelog on hover over the existing "Update available" pill — read-only and nightly-only. I'm opening this separately (rather than as the #2309 implementation) because the surface and scope are intentionally narrower; happy to fold it into #2309 if you'd prefer.
On the nightly channel, when an update is available the sidebar shows an "Update available" pill above Settings. Today it tells me that an update exists but not what it changes. To find out what's in the build I'm being asked to install, I have to leave the app and dig through GitHub releases. Nightly users update frequently and want a quick way to see what changed before downloading.
Proposed solution
When on the nightly channel and an update is available, hovering the "Update available" pill shows a tooltip with the changelog between the version I'm on and the latest one being offered. Release notes are grouped by version: the newest under "What's changed" and older intermediate versions under "Changes in <version>". If there are no notes (or the channel isn't nightly), the pill keeps its current plain tooltip.
Why this matters
Nightly users get context before updating without leaving the app, reducing blind updates and trips to GitHub. It's additive information on an element that already exists — no new surface, no workflow change.
Smallest useful scope
Nightly channel only, read-only display of the release notes electron-updater already fetches (via fullChangelog), rendered in the existing pill tooltip. Stable channel and any richer formatting can come later.
Alternatives considered
The broader approach tracked in #2309 (a dedicated toast/page when a new version is released) would show more, but adds new UI surface. This deliberately does less: no new element, just more info on one that already exists. Other options — opening release notes in a browser/external link, or a dedicated modal — add UI and clicks; a hover tooltip on the existing pill is the lightest touch.
Risks or tradeoffs
Release-note formatting from GitHub varies, so notes are sanitized (HTML/markdown stripped, boilerplate lines removed) and capped (max 6 version groups, 8 items each, 220 chars/item) to keep the tooltip bounded. Scoped to nightly to limit blast radius.
Examples or references
Before / after (dark mode):
| Before |
After |
 |
 |
Contribution
Before submitting
Area
apps/desktop (also touches apps/web and packages/contracts)
Problem or use case
Related to #2309 ("Provide Release notes via Toast when new version is released in Desktop App"). This is a much smaller, tighter-scoped take on the same underlying need: instead of a post-update toast/page, it surfaces the changelog on hover over the existing "Update available" pill — read-only and nightly-only. I'm opening this separately (rather than as the #2309 implementation) because the surface and scope are intentionally narrower; happy to fold it into #2309 if you'd prefer.
On the nightly channel, when an update is available the sidebar shows an "Update available" pill above Settings. Today it tells me that an update exists but not what it changes. To find out what's in the build I'm being asked to install, I have to leave the app and dig through GitHub releases. Nightly users update frequently and want a quick way to see what changed before downloading.
Proposed solution
When on the nightly channel and an update is available, hovering the "Update available" pill shows a tooltip with the changelog between the version I'm on and the latest one being offered. Release notes are grouped by version: the newest under "What's changed" and older intermediate versions under "Changes in
<version>". If there are no notes (or the channel isn't nightly), the pill keeps its current plain tooltip.Why this matters
Nightly users get context before updating without leaving the app, reducing blind updates and trips to GitHub. It's additive information on an element that already exists — no new surface, no workflow change.
Smallest useful scope
Nightly channel only, read-only display of the release notes electron-updater already fetches (via
fullChangelog), rendered in the existing pill tooltip. Stable channel and any richer formatting can come later.Alternatives considered
The broader approach tracked in #2309 (a dedicated toast/page when a new version is released) would show more, but adds new UI surface. This deliberately does less: no new element, just more info on one that already exists. Other options — opening release notes in a browser/external link, or a dedicated modal — add UI and clicks; a hover tooltip on the existing pill is the lightest touch.
Risks or tradeoffs
Release-note formatting from GitHub varies, so notes are sanitized (HTML/markdown stripped, boilerplate lines removed) and capped (max 6 version groups, 8 items each, 220 chars/item) to keep the tooltip bounded. Scoped to nightly to limit blast radius.
Examples or references
Before / after (dark mode):
Contribution