有关 2026.7 版本中发布的所有更改的更多信息，请参阅：
其他受支持版本的补丁版本也已发布：
这会成为当前的“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"
## 将 db_shared_buffers 设置为总内存的 25% 以内。
## 将根据检测到的 RAM 自动设置，或者你可以覆盖它
db_shared_buffers: "2048MB"
## 可以提高排序性能，但会增加每个连接的内存使用量
db_work_mem: "40MB"
## 减少最大上传大小
upload_size: 1m
## 此容器应使用哪个 Git 版本？（默认：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”版本，即现在的 2026.7。
您可以在 https://releases.discourse.org/ 找到有关支持周期以及 ESR 支持之间重叠的信息。
很遗憾，Discourse 无法降级。但如果您希望将来避免这种情况，可以将版本固定为 release/2026.7（并确保在 2026.7 停止支持之前手动更新该固定版本）。
2 个赞
谢谢。我想我在寻找一种最稳妥/自动化的方法，以确保始终停留在仍受支持的最旧版本上，即开发速度最慢的路径。
4 个赞
我也是这么想的，而且我认为 ESR（几乎）就是那样做的。每隔几个月就会有一个新的 ESR 发布，然后大家迁移到那个版本，最近刚刚发生了这种情况。但实际上，旧的 ESR 还有两个月的维护期，所以你会预期自己仍然停留在之前的那个 ESR 上。（我认为这是一个合理的需求。我们需要一个 esr-maintained 标签吗？）
5 个赞
我觉得这是一个值得考虑的想法，但也请考虑一下……一旦 v2026.1 停止维护，两个月后会有什么不同？
如果没有其他更改，届时你仍然会“在没有警告的情况下”收到更新。
这样可以吗？
2 个赞
是的，我认为坚持使用旧的 ESR 版本更长时间仍然很有意义。这意味着新的 ESR 已经过了一些测试，并且可能已经修复了一些问题。
我在发布后一小时内就升级到了新的 ESR，现在有些后悔：在当今的环境下，我最好锁定到上一个版本，仅接收安全更新。这将紧急的安全修复与管理员的学习曲线以及即将很快修复的新 bug 解耦。参见非常有帮助的
从 2026.1 ESR 升级到 2026.7 - 我的发现
（为什么预期刚发布的 ESR 会有新 bug？因为据我所知，新的 ESR 直到发布那一刻都在持续开发中。没有稳定期。）
3 个赞
这正是关键问题所在。
所以，如果我使用的是 esr-maintained 分支，那么两个月后，esr 和 esr-maintained 就会变成同一个分支，对吧？因此，两个月后我仍然会对这个重大变更感到惊讶。
在 esr 和 esr-maintained 尚未合并为同一分支期间，Discourse 可以发出/显示一条警告，提示你已进入“ESR 宽限期”。此警告仅应在论坛后台向管理员显示，而在重建容器时不显示。
如果能提前收到有关 ESR 轮换的通知，那就太好了，这样你就可以在这个受支持的宽限期内规划并测试升级。
4 个赞
在理想情况下，这为您提供了两个月的时间将暂存服务器更新到新的 ESR，同时在生产环境中运行旧的 ESR 并接收安全更新，以覆盖这一过渡期。
确实，设置某种简单的标签跟踪机制是有意义的，以便跟踪已打补丁的旧 ESR，从而自动获取其维护更新。
也许目前已经有办法实现这一点？
2 个赞
我认为 ESR 版本不会收到那么多 Bug 修复。就像 2026.1 版本一样，从今以后它只会接收安全更新。
因此，虽然一个月后其中的一些 Bug 可能已被知晓，但这并不意味着你就不必去处理它们。
3 个赞
持悲观态度来看，我们走着瞧！我想，如果在新发布的 ESR（长期支持版）中发现了某些愚蠢的破坏性变更，它们会被修复。也许这个新体系尚未运行足够长的时间，让我们看到这种情况发生。事实上，我并不期望那些仅仅是造成不便的问题会得到修复。
2 个赞