For more information on all the changes released in 2026.7, check out:
Patch releases for other supported versions have also been released:
4 likes
Does this become the current “esr” release or have I misunderstood something?
1 like
Indeed, I can’t figure out what happened. For this update (very urgent due to Cache poisoning/XSS via color scheme cookies · Advisory · discourse/discourse · GitHub) it required a rebuild, but since there was a v2026.1.5 → v2026.1.6 changelog I assumed it would be a minor version bump. But nope, now I’m on v2026.7.0. As far as I know my forum is configured to be on esr :
params:
db_default_text_search_config: "pg_catalog.english"
## Set db_shared_buffers to a max of 25% of the total memory.
## will be set automatically by bootstrap based on detected RAM, or you can override
db_shared_buffers: "2048MB"
## can improve sorting performance, but adds memory usage per-connection
db_work_mem: "40MB"
## Reduce max upload size
upload_size: 1m
## Which Git revision should this container use? (default: tests-passed)
version: esr
I was also rather surprised to see a whole bunch of post update queries like this:
== 20260421061908 AddCoveringIndexOnChatMessagesThreadId: migrating ===========
-- remove_index(:chat_messages, {name: "idx_chat_messages_thread_id_id_user_id_not_deleted", algorithm: :concurrently, if_exists: true})2026-07-28 16:02:43.673 UTC [544] discourse@discourse LOG: duration: 16903.716 ms statement: CREATE INDEX CONCURRENTLY "index_posts_on_updated_at_for_localization" ON "posts" ("updated_at" DESC) WHERE deleted_at IS NULL AND user_id > 0 AND locale IS NOT NULL
2026-07-28 16:02:59.214 UTC [544] discourse@discourse LOG: duration: 15529.318 ms statement: CREATE INDEX CONCURRENTLY "index_posts_on_updated_at_for_locale_detection" ON "posts" ("updated_at" DESC) WHERE deleted_at IS NULL AND user_id > 0 AND locale IS NULL
2026-07-28 16:03:00.031 UTC [544] discourse@discourse LOG: duration: 798.943 ms statement: CREATE INDEX CONCURRENTLY "index_topics_on_updated_at_for_locale_detection" ON "topics" ("updated_at" DESC) WHERE deleted_at IS NULL AND user_id > 0 AND locale IS NULL
2026-07-28 16:03:00.186 UTC [544] discourse@discourse LOG: duration: 143.500 ms statement: CREATE INDEX CONCURRENTLY "index_topics_on_updated_at_for_localization" ON "topics" ("updated_at" DESC) WHERE deleted_at IS NULL AND user_id > 0 AND locale IS NOT NULL
2026-07-28 16:03:01.251 UTC [544] discourse@discourse LOG: duration: 1051.872 ms statement: UPDATE posts
SET raw = regexp_replace(
raw,
'\\+([_*~|`])(?=[^\]\[]*\]\(upload://)',
'\1',
'g'
)
WHERE id >= 1
AND id < 10001
AND raw ~ '\\+[_*~|`][^\]\[]*\]\(upload://'
2026-07-28 16:03:01.910 UTC [544] discourse@discourse LOG: duration: 658.965 ms statement: UPDATE posts
SET raw = regexp_replace(
raw,
'\\+([_*~|`])(?=[^\]\[]*\]\(upload://)',
'\1',
'g'
)
WHERE id >= 10001
AND id < 20001
AND raw ~ '\\+[_*~|`][^\]\[]*\]\(upload://'
2 likes
Yes, it is!
This release is a new ESR release, so you moved to it when you updated.
3 likes
In the future could this somehow be made less confusing? Maybe it’s just me, but if an update is applied to the ESR branch I’m currently on then I assume it’s because the current major version of that branch is still supported.
2 likes
2026.1 is still supported, and you can pin your installation to it by setting version: release/2026.1 in your app.yml. In that case, running a rebuild would’ve pulled in the security update on the 2026.1 branch.
I guess you were using version: esr? In that case, you are tracking the ‘latest esr’ version, which is now 2026.7.
You can find information on the support periods, and the overlaps between ESR support, on https://releases.discourse.org/
Unfortunately it isn’t possible to downgrade Discourse. But if you’d like to avoid this in future, you can pin to release/2026.7 (and make sure to update that pin manually before 2026.7 drops out of support).
1 like
Thanks. I guess I’m looking for the most foolproof/automated way to definitely remain on the oldest version that is still supported, i.e. the slowest development path.
3 likes
Same here, and I think esr (nearly) does that. Every few months there’s a new esr and you move to that, which is what just happened. But in fact the old esr has another two months of maintained lifespan, so you expected to stay on that previous esr. (I think that’s a reasonable thing to want to do. Do we need an esr-maintained label??)
4 likes
I think it’s a reasonable thing to consider, but also consider this… what would be different 2 months later, once v2026.1 stops being maintained?
Without additional changes, you’d still be updated at that time “without warning”.
Is that OK?
1 like
Yes, I think it still makes sense to want to stick at the old esr for longer. It means the new esr has had some testing and may have picked up some fixes.
I picked up the new esr within an hour and I somewhat regret it: in the present world I would be best-advised to pin to the previous and get only the security fixes. It decouples the urgent security fix from the administrative learning curve and any new bugs which will shortly be fixed. See the very helpful
Jumping from 2026.1 ESR to 2026.7 - What I found
(Why expect new bugs in a freshly minted esr? Because, as far as I can tell, the new esr was in continuous development until the moment of release. There is no stabilisation phase.)
2 likes
That is the big question.
So if I was on esr-maintained then after two months, esr and esr-maintained would be the same branch, right? So after 2 months I would still be surprised about the big change.
While esr and esr-maintained are not the same branch, then Discourse could issue/display a warning that you are entered the “grace esr period”. This warning could only be shown on the forum to admins, and not when rebuilding the container.
Having the advance notice about the ESR-rollover would be nice so you can plan and test the upgrade during this supported grace period.
4 likes
In an ideal world this gives you two months to update your staging server to the new esr whilst in Production you get to run the old esr with security updates to cover this period.
It does indeed make sense to have some kind of simple label tracking to follow the patched old esr so you pick up the maintained updates of old esr automatically.
Perhaps there’s a way of achieving this already?
2 likes
I don’t think the ESR will receive that many bug fixes. Just like 2026.1 - it will only get security fixes from now on
So while in a month some of those bugs might be known, it doesn’t mean that you don’t have to deal with them
3 likes
To take a pessimistic stance, we’ll see! I imagine if there were some silly breaking change found in a freshly minted esr then it would be fixed. Perhaps this new world hasn’t yet been in place long enough to see that happen. Indeed I wouldn’t expect fixes to mere inconveniences.
1 like