# July 2026 monthly release
**URL:** https://meta.discourse.org/t/july-2026-monthly-release/408729
**Category:** Announcements
**Tags:** release-notes
**Created:** [July 28, 2026, 3:13pm UTC](https://meta.discourse.org/t/july-2026-monthly-release/408729 "2026-07-28T15:13:30Z")
**Posts on this page:** 14
**Page:** 1
### Author:  [@loic](https://meta.discourse.org/u/loic)
#### Post date: [July 28, 2026, 3:13pm UTC](https://meta.discourse.org/t/july-2026-monthly-release/408729/1 "2026-07-28T15:13:30Z")
For more information on all the changes released in 2026.7, check out:
> **[v2026.7.0 Changelog | Discourse Releases](https://releases.discourse.org/changelog/v2026.7.0/)**
>
> Featured changes and detailed commit history for Discourse 'v2026.7.0'.
Patch releases for other supported versions have also been released:
- [v2026.1.6 Changelog | Discourse Releases](https://releases.discourse.org/changelog/v2026.1.6)
- [v2026.5.2 Changelog | Discourse Releases](https://releases.discourse.org/changelog/v2026.5.2)
- [v2026.6.1 Changelog | Discourse Releases](https://releases.discourse.org/changelog/v2026.6.1)
---
### Author:  [@merefield](https://meta.discourse.org/u/merefield)
#### Post date: [July 28, 2026, 3:15pm UTC](https://meta.discourse.org/t/july-2026-monthly-release/408729/2 "2026-07-28T15:15:23Z")
Does this become the current “esr” release or have I misunderstood something?
---
### Author:  [@rahim123](https://meta.discourse.org/u/rahim123)
#### Post date: [July 28, 2026, 4:20pm UTC](https://meta.discourse.org/t/july-2026-monthly-release/408729/3 "2026-07-28T16:20:00Z")
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](https://github.com/discourse/discourse/security/advisories/GHSA-qx4v-rg4v-pm2g)) it required a rebuild, but since there was a [v2026.1.5 → v2026.1.6](https://releases.discourse.org/changelog/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` :
```plaintext
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:
```plaintext
== 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://'
```
---
### Author:  [@Falco](https://meta.discourse.org/u/Falco)
#### Post date: [July 28, 2026, 4:40pm UTC](https://meta.discourse.org/t/july-2026-monthly-release/408729/4 "2026-07-28T16:40:02Z")
> [@merefield](#):
>
> Does this become the current “esr” release or have I misunderstood something?
Yes, it is!
> [@rahim123](#):
>
> As far as I know my forum is configured to be on `esr`
This release is a new ESR release, so you moved to it when you updated.
---
### Author:  [@rahim123](https://meta.discourse.org/u/rahim123)
#### Post date: [July 28, 2026, 4:49pm UTC](https://meta.discourse.org/t/july-2026-monthly-release/408729/5 "2026-07-28T16:49:32Z")
> [@rahim123](#):
>
> but since there was a [v2026.1.5 → v2026.1.6](https://releases.discourse.org/changelog/v2026.1.6/) changelog I assumed it would be a minor version bump.
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.
---
### Author:  [@david](https://meta.discourse.org/u/david)
#### Post date: [July 28, 2026, 5:20pm UTC](https://meta.discourse.org/t/july-2026-monthly-release/408729/6 "2026-07-28T17:20:45Z")
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/](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).
---
### Author:  [@rahim123](https://meta.discourse.org/u/rahim123)
#### Post date: [July 28, 2026, 5:25pm UTC](https://meta.discourse.org/t/july-2026-monthly-release/408729/7 "2026-07-28T17:25:16Z")
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.
---
### Author:  [@Ed\_S](https://meta.discourse.org/u/Ed_S)
#### Post date: [July 28, 2026, 5:51pm UTC](https://meta.discourse.org/t/july-2026-monthly-release/408729/8 "2026-07-28T17:51:06Z")
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??)
---
### Author:  [@mcwumbly](https://meta.discourse.org/u/mcwumbly)
#### Post date: [July 29, 2026, 1:40am UTC](https://meta.discourse.org/t/july-2026-monthly-release/408729/9 "2026-07-29T01:40:54Z")
> [@Ed\_S](#):
>
> I think that’s a reasonable thing to want to do. Do we need an esr-maintained label??
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?
---
### Author:  [@Ed\_S](https://meta.discourse.org/u/Ed_S)
#### Post date: [July 29, 2026, 6:04am UTC](https://meta.discourse.org/t/july-2026-monthly-release/408729/10 "2026-07-29T06:04:45Z")
> [@mcwumbly](#):
>
> Is that OK?
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](https://meta.discourse.org/t/jumping-from-2026-1-esr-to-2026-7-what-i-found/408779)
(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.)
---
### Author:  [@elmuerte](https://meta.discourse.org/u/elmuerte)
#### Post date: [July 29, 2026, 6:31am UTC](https://meta.discourse.org/t/july-2026-monthly-release/408729/11 "2026-07-29T06:31:41Z")
> [@mcwumbly](#):
>
> 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?
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.
---
### Author:  [@merefield](https://meta.discourse.org/u/merefield)
#### Post date: [July 29, 2026, 6:39am UTC](https://meta.discourse.org/t/july-2026-monthly-release/408729/12 "2026-07-29T06:39:39Z")
> [@Ed\_S](#):
>
> But in fact the old esr has another two months of maintained lifespan, so you expected to stay on that previous esr.
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?
---
### Author:  [@Moin](https://meta.discourse.org/u/Moin)
#### Post date: [July 29, 2026, 7:15am UTC](https://meta.discourse.org/t/july-2026-monthly-release/408729/13 "2026-07-29T07:15:23Z")
> [@Ed\_S](#):
>
> any new bugs which will shortly be fixed
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
> [@Understanding Discourse release channels](https://meta.discourse.org/t/understanding-discourse-release-channels/264400/1):
>
> The ESR channel is not necessarily more “stable” than **latest**. It’s more about the idea that the bugs are known, and it serves as a checkpoint for a specific set of features and improvements. With **latest** , there may be new bugs introduced, then fixed a few commits later.
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
---
### Author:  [@Ed\_S](https://meta.discourse.org/u/Ed_S)
#### Post date: [July 29, 2026, 12:38pm UTC](https://meta.discourse.org/t/july-2026-monthly-release/408729/14 "2026-07-29T12:38:08Z")
> [@Moin](#):
>
> 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
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.