For more information on all the changes released in 2026.1, check out:
This is the first “ESR” release of Discourse, and replaces the old “stable” branch. Sites tracking stable will be upgraded from 3.5 to 2026.1 on their next upgrade. To see all changes from 3.5 to 2026.1, use this link.
Patch releases for other supported versions have also been released:
2026.1.0 being also the first esr release.
For people on the previously existing stable branch (which is now aliased to esr), will go from 3.5.3 to 2026.1.0; and not 3.5.4
So let me see I’ve until april to not update (3 months) when v2026.1 being deprecated my current version will be ESR right? all this changes is a little confuse
Yes, unless they are using the v3.5.4 tag to keep themselves on 3.5.
The diagram on the homepage of https://releases.discourse.org/ is the best way to visualise things.
Whatever release stream you choose, you’ll always need to update regularly for critical security fixes. The question is whether you also want to pull in new features & other changes along with the security fixes (if so, use release or latest), or whether you prefer to have a 6-monthly-ish cadence for those (if so, use esr).
It’s still early days for this new numbering scheme, so the documentation & tooling will continue to evolve as we grow into the new system.
It was v2026.0 when I updated for the last time in december and now v2026.2 it will became ESR in april right?
Take a look at the releases.discourse.org homepage for all the support information. 2026.1 is the current extended support release, and will be supported until September 2026.
2026.2 will be released in February, and will receive security fixes for 2 months after that. It won’t be an extended-support-release.
Is 2026.1.0 the first stable/ESR release to drop support for iOS and other old browsers? That’s a big enough change it should be listed somewhere in the release notes. I couldn’t find anything about it in the “detailed changes” search box at the end though.
Oh, I think that’s cause you’ve linked to the changelog for v2026.1.0-latest → v2026.1.0. If you change it to v3.5.3 → v2026.1.0 then it shows 2397 detailed changes, rather than only 369. For these ESR releases you really should be linking to the last ESR release instead of -latest (is that like a RC?)
I still can’t see which change clearly marked the dropping of support for the old browsers, but I could find this one at least: FIX: Update 'modern mobile' regex following iOS 15 support drop by davidtaylorhq · Pull Request #34792 · discourse/discourse · GitHub
Yes 
Yup. The vast majority of people use the latest or release streams of Discourse, so that’s what the changelog site is optimised for. People choosing ESR are essentially ‘skipping 5 versions’ each time they upgrade, so you’d need to look at the changes for each of those intermediate versions.
You can do that by browsing each intermediate changelog, or you can use the filters to generate a custom changelog spanning the full range (as you’ve done). Perhaps we can improve the releases site UX to have some kind of quick-link to jump to an ESR → ESR comparison.
Looking back to the last ‘stable’ release, we didn’t have a ‘mega-changelog’ for that either. People had to read each of the intermediate beta changelogs for a full picture of the changes. So I think we’re moving in the right direction here - at least it’s now possible to see a full changelog, even if it’s not the smoothest UX.
For now, I’ve added a link to that ESR → ESR comparison in the OP here:
Thanks for the feedback!
Whether from a particular release to another or from an arbitrary point in latest to the latest latest, if a change between commits x and y cannot be applied by the built-in updater, instead requiring the container be rebuilt from a new image, will the new release notes system identify that and make note of the need for a rebuild?
Separately, will the built-in updater prevent the update, prompting for a rebuild?
My loose understanding of the built-in updater is that after updating Docker_manager, it will block updating Discourse if a rebuild is required. I haven’t seen this formalised though and anecdotally it hasn’t seemed completely reliable.
Specifically, sometimes navigating from the completed Docker_manager update to the Versions page will have the Discourse update available to start, then only after refreshing the page will it be blocked. [I will note that the last time I saw that happen was quite a long time ago though, maybe it was fixed.]
The need for a rebuild is related to the ‘Docker base image’ of Discourse, which is totally decoupled from the Discourse version number. We require it when there are critical changes to the OS-level dependencies inside the docker image.
So it would be tricky to include in the Discourse core release notes. But I do hear you on it being surprising/frustrating to not be able to update from the UI. Perhaps there are improvements we can make to the UI there.
I could imagine this working by:
That said, we’ve still got some other fish to fry right now that are currently more important for the versioning work overall (e.g. the theme component / plugin compatibility stuff)