作为我们正在进行的项目（旨在彻底改革我们的版本编号和发布流程）的一部分，我们很高兴地宣布 releases.discourse.org。
从今以后，该网站将成为有关 Discourse 版本、其发布日期、支持时间表和更改日志的主要信息来源。
在主页上，您会找到近期版本及其开发/支持周期的可视化展示。然后，您可以点击查看特定版本的更改日志。例如，最近的 2025.12.0 版本：
对于未来的版本，我们将链接到这些页面，而不是在 Meta 上撰写专门的 release-notes 主题。
该网站还支持为任何版本/提交范围生成自定义更改日志。我们打算开始从 Discourse 本身中的升级用户界面 (UI) 链接到这些更改日志。
如果您有任何反馈，请告诉我们！
我在哪里可以找到目前包含在 releases.discourse.org 上的 release-notes 中的插件提交？
一个小功能请求：
您能否为“详细更改”下所列的各个更改（commit-card）添加锚点链接？
这样分享特定更改一定会更容易 : )
核心插件的更改与其他核心更改一起包含在内，因此缺少的是“非核心官方插件”。将其他仓库的更改添加进来是我们将来可能会考虑的事情，但目前没有立即实施的计划。
对于非核心插件（包括官方和第三方），GitHub 可能是目前跟踪其更改的最佳方式。
好主意！实现起来可能有点棘手，因为提交列表是作为“虚拟列表”实现的，其中只渲染了屏幕上显示的元素……但我会尽力而为。
真令人失望。我发现发布说明中最有趣的部分是对不在 discourse/discourse 仓库中的插件的总结。我可以在 GitHub 上一处找到核心中的所有更改。但是其他插件的更改发生在不同的仓库中，因此没有一个地方可以轻松地跟踪所有这些更改。
看起来是可视化活跃开发和支持生命周期的一种好方法。
我注意到 v2026.01 版本被标记为 [latest]，但不像 v3.5 那样也标记为 [ESR]。同时拥有两者将是一个有用的快速参考。
鉴于版本发布和活跃开发之间有额外信息，是否有任何设置（或计划添加）可以将 Discourse 保持在某个发布版本或 ESR 版本上？
关于此事的另一件事是：我们在RFC中计划为插件和主题构建一些自动化，以创建与不同版本的 Discourse 兼容的分支。
我认为我们应该在就绪后再回来讨论这个问题。
现在可以通过在部署配置中设置要跟踪的分支来实现此目的：
但是，一旦你这样做了，你就永远被固定在该版本上了。我们仍然需要构建的是一种更好的方法来查看何时有新版本可用（在你关注的任何发布渠道上）。
我们已经就这可能如何运作进行了一些初步讨论，但仍在讨论细节。
这太棒了，可以让我一眼快速了解我当前使用的版本以及何时需要计划升级到下一个版本！非常喜欢这个页面 
我喜欢安全修复和主要功能被突出显示！我希望破坏性变更也能得到类似的突出显示。
另外，我建议 ESR（延长支持版本）的生命周期应该再延长一点时间（也许一两个月），这样人们就可以在两个 ESR 都处于非活跃开发但仍在支持期时，从一个 ESR 切换到另一个。否则，社区基本上需要在等待并短暂失去支持，或者提前升级并仍在支持中但不得不接受更多开发中更新之间做出选择。有一个小的重叠可以让一个分支有机会变得更稳定。这在 ESR 生命周期中相当常见，例如 MediaWiki：
这不需要太花哨，只需为较旧的 ESR 分支提供额外一两个月的高优先级安全修复即可。
不过无论如何都要感谢，这确实有助于澄清很多问题 ^.^
是的，在新的发布系统中，我们计划为 ESR 支持提供 2 个月的重叠期。因此，2026.1 将支持到 9 月，这将是 2026.7 ESR 发布后的 2 个月。
不幸的是，对于现有的“稳定版”3.5，我们很难提供这种重叠支持，因为它没有专门的分支。但从 2026.1 开始，对于那些希望不那么频繁更新的人来说，情况会好得多。
听起来很棒，谢谢！
