July 2026 monthly release

News and Events Announcements
1

For more information on all the changes released in 2026.7, check out:

Patch releases for other supported versions have also been released:

3 Likes
2

Does this become the current “esr” release or have I misunderstood something?

3

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
4

Yes, it is!

This release is a new ESR release, so you moved to it when you updated.

2 Likes
5

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
6

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
7

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.

2 Likes
8

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??)

image
image1398×864 41 KB

3 Likes