2026年7月月度版本

新闻和活动 公告
1

有关 2026.7 版本中发布的所有更改的更多信息，请参阅：

其他受支持版本的补丁版本也已发布：

3 个赞
2

这会成为当前的“esr”版本，还是我理解错了什么？

3

确实，我无法弄清楚发生了什么。对于这次更新（由于 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 个赞
4

是的，没错！

此次发布是一个新的 ESR 版本，因此您在更新后已切换至该版本。

2 个赞
5

未来能否让这种情况不那么令人困惑呢？也许只是我个人的感觉，但如果更新应用到我当前所在的 ESR 分支，我会认为这是因为该分支的当前主版本仍然受支持。

1 个赞
6

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 停止支持之前手动更新该固定版本）。

1 个赞
7

谢谢。我想我在寻找一种最稳妥/自动化的方法，以确保始终停留在仍受支持的最旧版本上，即开发速度最慢的路径。

1 个赞
8

我也是这么想的，而且我认为 ESR（几乎）就是那样做的。每隔几个月就会有一个新的 ESR 发布，然后大家迁移到那个版本，最近刚刚发生了这种情况。但实际上，旧的 ESR 还有两个月的维护期，所以你会预期自己仍然停留在之前的那个 ESR 上。（我认为这是一个合理的需求。我们需要一个 esr-maintained 标签吗？）

image
image1398×864 41 KB

1 个赞