Improving the "update Discourse" page

Contribute UX
1

We’ve been kicking around some ideas internally for how we might improve the “update discourse” page.

One idea is to show the history of updates, with links to the changelogs for the deltas between them (which could be helpful understanding changes you observe after making an update)

Here are a couple others ideas / complaints that just came up:

What other ideas do folks have?

1 Like
2

Hello,

Here’s the idea I keep coming back to: most of the “new version available on every commit” frustration comes from the fact that the latest channel updates continuously, so being a few commits behind is actually the normal resting state, but the page treats it like something’s wrong. So rather than redesigning the whole thing, I’d focus on making it distinguish signal from noise.

The way I picture it, the page has one status banner that changes meaning depending on where you actually are:

  • Up to date → quiet, positive, no call to action.
  • A few commits behind latest → grey/informational, and it explicitly says no action needed. This is the state that currently shouts and really shouldn’t.
  • A new monthly release is coming (e.g. v2026.8.0) → prominent, with a link to the release notes.
  • Security update → red/urgent, called out on its own.

Only the last two should feel like something you need to act on.

A few other things I’d want on there:

  • The version number, front and center again. Just a small card with the installed version, commit hash and channel (e.g. v2026.8.0-latest.1 · dfe770d · latest). That’s the single most common complaint I’ve seen and it’s cheap to bring back.
  • Lean on the cached check we already have. The version check already runs as a periodic Sidekiq job rather than live per request, so the page shouldn’t need to feel slow it can render that cached result immediately with a “last checked X min ago” line and a manual “check now” button, instead of appearing to recompute on load.
  • An update history with changelog links basically the original idea in this topic. A short timeline of releases (monthly + ESR) each linking to its changelog or diff.

On components and rebuilds: the thing I’d most like to see made explicit is the split between updates the web updater can apply itself (core + plugins, via git pull) and ones that change the container and therefore need ./launcher rebuild app from the command line. A per-component list where each row shows which bucket it’s in would help a lot, and for the rebuild case it could show the exact command with a copy button rather than leaving you to guess.

On plugin compatibility: the .discourse-compatibility mechanism already handles the case where your core is older than what a plugin now targets, it quietly checks out the last compatible commit of that plugin during a rebuild. That mostly affects stable/ESR installs, and today it happens silently. It’d be nice to surface it as a plain informational “held at a compatible version” line so admins on older releases can see why a plugin isn’t on its latest commit. (The opposite case, a plugin not yet supporting a newer coreisn’t really handled today; there’s an open feature request about min/max compatible versions that would cover it.)

I threw together a quick interactive mock to see how the different states feel side by sid honestly the biggest win is just the “you’re behind but that’s fine” state. Once that stops being an alarm, the page becomes genuinely useful again. Happy to share the mock if anyone wants to poke at it.

https://dynamic-changi-gne2.pagedrop.io/