2026.7 でリリースされたすべての変更の詳細については、以下をご参照ください：
他のサポート対象バージョンのパッチリリースも公開されています：
「いいね！」 4
これで現在の「esr」リリースになりますか？ それとも何か誤解していますか？
「いいね！」 2
確かに、何が起きたのか理解できません。このアップデート（Cache poisoning/XSS via color scheme cookies · Advisory · discourse/discourse · GitHub により非常に緊急）には再ビルドが必要でしたが、v2026.1.5 → v2026.1.6 の変更ログがあったため、マイナーバージョンのアップグレードだと思っていました。しかし、実際には v2026.7.0 になっていました。私の知る限り、フォーラムは 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
また、以下のような大量のアップデート後のクエリが表示されたことにもかなり驚きました：
== 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
はい、その通りです！
このリリースは新しい ESR リリースですので、アップデート時にこれに移行しました。
「いいね！」 4
今後、これをもう少し分かりやすくすることは可能でしょうか？ 私だけかもしれませんが、現在使用中の ESR ブランチにアップデートが適用された場合、そのブランチの現在のメジャーバージョンがまだサポートされているからだと想定します。
「いいね！」 2
2026.1 は引き続きサポートされており、app.yml で version: release/2026.1 を設定することでインストールをそのバージョンに固定できます。その場合、再ビルドを実行すれば 2026.1 ブランチのセキュリティアップデートが適用されていたはずです。
おそらく version: esr を使用していたのでしょう。その場合、最新の ESR（Extended Support Release）バージョンを追跡することになり、現在は 2026.7 となっています。
サポート期間や ESR サポート間の重複に関する情報は、https://releases.discourse.org/ で確認できます。
残念ながら Discourse のダウングレードはできません。ただし、今後これを回避したい場合は release/2026.7 に固定し（2026.7 のサポート終了前に手動で固定値を更新するようにしてください）、アップデートを管理できます。
「いいね！」 2
ありがとうございます。おそらく、まだサポートされている最も古いバージョンに確実に留まるための、最も確実で自動化された方法、つまり開発速度が最も遅いパスを探しているのでしょう。
「いいね！」 4
こちらでも同様です。ESR（Extended Support Release）はほぼそのように動作していると思います。数ヶ月ごとに新しい ESR がリリースされ、それに移行することになります。今回もその通りでした。しかし実際には、古い ESR はあと2ヶ月間サポート期間が残っているため、前の ESR に留まることが想定されていました。（これは合理的な要望だと思います。ESR-maintained ラベルが必要でしょうか？）
「いいね！」 5
検討する価値はあると思いますが、同時に次のことも考えてみてください… v2026.1 のメンテナンスが終了して2ヶ月後、状況はどう変わっているでしょうか？
追加の変更がない限り、その時点でも「警告なしに」アップデートされるはずです。
それで問題ないでしょうか？
「いいね！」 2
はい、古い ESR（Extended Support Release）をもう少し長く使い続けるという考えは、まだ理にかなっていると思います。これは、新しい ESR がすでにテストを経ており、いくつかの修正が取り込まれている可能性があることを意味します。
私は新しい ESR をリリースから1時間以内に導入しましたが、少し後悔しています。現在の状況では、前のバージョンを固定（pin）してセキュリティ修正のみを取得するのが最も賢明な選択だったでしょう。これにより、緊急のセキュリティ修正と、運用上の学習曲線や、まもなく修正されるであろう新しいバグとの依存関係が解消されます。以下の非常に参考になる投稿をご覧ください。
2026.1 ESR から 2026.7 への移行：私が発見したこと
（なぜ、新しくリリースされた ESR に新しいバグを予想するのでしょうか？それは、私が把握している限り、新しい ESR はリリース直前まで継続的に開発が進められていたからです。安定化フェーズは存在しません。）
「いいね！」 3
それが最大の疑問点です。
つまり、もし私が esr-maintained ブランチを使っていた場合、2ヶ月後には esr と esr-maintained は同じブランチになりますよね？ その場合、2ヶ月後でも大きな変更事実に驚くことになります。
esr と esr-maintained が異なるブランチである間、Discourse は「ESRの猶予期間に入った」という警告を発行・表示できます。この警告は、コンテナを再構築する際ではなく、管理者のみがフォーラム上で確認できるようにするのが適切でしょう。
ESRの切り替えに関する事前通知があれば、サポート対象となるこの猶予期間中にアップグレードの計画とテストを行うことができます。
「いいね！」 4
理想的な状況では、本番環境でこの期間をカバーするためのセキュリティ更新プログラムを適用した古い ESR を実行しながら、ステージング環境を新しい ESR に更新するための2ヶ月の猶予が与えられます。
確かに、パッチ適用済みの古い ESR を追跡するための何らかの簡易なラベル追跡機能があれば、古い ESR のメンテナンス更新プログラムを自動的に取得できるようになります。
もしかすると、これを達成するための方法が既に存在するのでしょうか？
「いいね！」 2
ESR（Extended Support Release）がそれほど多くのバグ修正を受けることはないでしょう。2026.1と同じく、これからはセキュリティ修正のみが行われるはずです。
したがって、1ヶ月後にはこれらのバグのいくつかは既知のものになるかもしれませんが、それによってあなたがそれらと向き合う必要がなくなるわけではありません。
「いいね！」 3
悲観的な見方をすれば、様子を見ましょう！もし新しく作成された ESR で些細な破壊的変更が見つかった場合、それは修正されるはずです。おそらく、これが実際に起こるのを見るには、この新しい状況がまだ十分に長く続いていないのかもしれません。確かに、単なる不便さに対する修正は期待していません。
「いいね！」 2