2026年1月发布

公告
1

有关 2026.1 中发布的所有更改的更多信息，请查看：

这是 Discourse 的第一个“ESR”（长期支持）版本，取代了旧的“stable”（稳定版）分支。跟踪稳定版的站点在下次升级时将从 3.5 升级到 2026.1。要查看从 3.5 到 2026.1 的所有更改，请使用此链接。

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

12 个赞
2

2026.1.0 也将是第一个 esr 版本。

对于先前存在的 stable 分支（现已别名为 esr）的用户，将从 3.5.3 升级到 2026.1.0；而不是 3.5.4。

2 个赞
3

所以让我看看，我还有到四月才需要更新（3个月），当 v2026.1 被弃用时，我的当前版本将是 ESR，对吗？所有这些更改有点令人困惑。

1 个赞
4

是的，除非他们使用 v3.5.4 标签来保持在 3.5 版本。

https://releases.discourse.org/ 主页上的图表是可视化这些情况的最佳方式。

无论您选择哪个发布流，您始终需要定期更新以获取关键的安全修复。问题在于您是希望在安全修复的同时引入新功能和其他更改（如果是这样，请使用 release 或 latest），还是更喜欢以大约每六个月的节奏进行（如果是这样，请使用 esr）。

这个新的编号方案仍处于早期阶段，因此随着我们适应新系统，文档和工具将继续发展。

3 个赞
5

我上次在十二月更新时是 v2026.0，现在是 v2026.2，它将在四月变为 ESR，对吗？

6

请查看 releases.discourse.org 主页以获取所有支持信息。2026.1 是当前的扩展支持版本，将支持到 2026 年 10 月。

2026.2 将于二月发布，之后会收到 2 个月的安全修复。它将不是一个扩展支持版本。

2 个赞
7

2026.1.0 是第一个弃用对 iOS 和其他旧版浏览器的支持（https://meta.discourse.org/t/dropping-ios-15-other-old-browsers-in-july-2025/358131）的稳定版/ESR 版本吗？这是一个足够大的变更，应该在某个地方的发布说明中列出。我在末尾的“详细更改”搜索框中找不到任何相关信息。

哦，我想那是因为您链接到了 v2026.1.0-latest → v2026.1.0 的更改日志。如果您将其更改为 v3.5.3 → v2026.1.0，它会显示 2397 个详细更改，而不是只有 369 个。对于这些 ESR 版本，您真的应该链接到上一个 ESR 版本而不是 -latest（这算是一个 RC 吗？）

我仍然看不到哪个更改明确标记了弃用对旧版浏览器的支持，但我至少找到了这个：FIX: Update 'modern mobile' regex following iOS 15 support drop by davidtaylorhq · Pull Request #34792 · discourse/discourse · GitHub

2 个赞
8

是的 :+1:

没错。绝大多数人使用 Discourse 的 latest 或 release 流，因此发布日志网站是为此优化的。选择 ESR 的用户每次升级时实际上都在“跳过 5 个版本”，因此您需要查看每个中间版本的更改。

您可以通过浏览每个中间更改日志来实现，或者使用过滤器来生成跨越整个范围的自定义更改日志（正如您所做的那样）。也许我们可以改进发布网站的用户体验，增加某种快速链接，以便跳转到 ESR → ESR 的比较。

回顾 上一个“稳定版”发布 时，我们也没有“超级更改日志”。人们必须阅读每个中间测试版更改日志才能全面了解所做的更改。所以我想我们正朝着正确的方向前进——至少现在可以看到完整的更改日志了，即使用户体验不是很顺畅。

目前，我已在帖子首部添加了一个指向该 ESR → ESR 比较的链接：

感谢您的反馈！

4 个赞
9

无论是从一个特定的版本到另一个版本，还是从 latest 中的任意一点到最新的 latest，如果内置更新程序无法应用提交 x 和 y 之间的更改，而是需要从新映像重建容器，新的发布说明系统会识别到这一点并记录需要重建的必要性吗？

另外，内置更新程序会阻止更新，提示需要重建吗？

我对内置更新程序的粗略理解是，在更新 Docker_manager 之后，如果需要重建，它会阻止更新 Discourse。我没有看到这被正式化，而且根据经验来看，它似乎并不完全可靠。

具体来说，有时从已完成的 Docker_manager 更新导航到“版本”页面时，Discourse 更新会立即可用，但只有在刷新页面后，它才会被阻止。[我将指出，我上次看到这种情况发生是在很久以前了，也许它已经被修复了。]

1 个赞
10

重建的需要与 Discourse 的“Docker 基础镜像”有关，它与 Discourse 的版本号完全脱钩。当 Docker 镜像内部的操作系统级别依赖项发生重大变化时，我们需要它。

因此，将其包含在 Discourse 核心发布说明中会很棘手。但我理解您对无法从 UI 更新感到惊讶/沮丧。也许我们可以在 UI 方面进行改进。

4 个赞
11

我能想象这可以通过以下方式实现：

  • 在主页上设置一个“发布渠道”过滤器
    • 所有发布
    • 扩展支持发布 (ESR)
  • 查看 ESR 渠道时，只列出这些发布，点击某个发布会链接到它们之间的差异

话虽如此，我们目前还有其他更重要的事情需要处理，这些事情对版本控制工作整体来说更重要（例如主题组件/插件兼容性相关内容）。

1 个赞
12

哦，我认为并非总能使用 UI 进行更新是可以接受的，任何（个人、企业等）自托管 Discourse 的人必须（应该）有具备基本服务器管理技能的人员来执行诸如保持主机系统最新和重建 Discourse 等任务。

在我看来，最重要的事情是：

  • 如果更新依赖于使用更新的 Docker 镜像进行重建（以至于没有它就会中断），则不应允许从 UI 进行更新
  • 当需要重建时，应该可见

只要 UI 在更新 Docker_manager 后始终正确更新，即不会出现它知道 Docker_manager 已是最新但不知道需要重建的状态，我认为这两点已经成立。

4 个赞