我们计划为 Discourse 引入新的版本控制系统。我们的目标是在保持开发速度的同时，为社区管理员提供更多的选择和可预测性。我们还将调整一些术语，使其与其他软件更好地对齐。
随着我们收到反馈、开始实施该系统以及随后扩展新发布流的使用，本文档将不断更新。
如果您在此阶段有任何意见/建议，请回复此主题告知我们！
目标
-
为 Discourse 引入更常规的“发布”，在开发速度和稳定性之间取得平衡。
-
继续提供大约每 6 个月一次的发布，并提供延长支持。
-
为常规发布和长期支持发布提供重叠支持，以便管理员在更新时间上拥有更大的灵活性，同时继续接收关键安全更新。
-
尽量减少“发布”的仪式。尽可能自动化，并且不应减慢核心开发人员的体验。ESR 发布与其他任何发布一样。
-
命名和流程应符合行业标准，以便更容易向开发人员和最终用户解释。
高层概述
-
大约每月发布一次。‘主’版本是当前年份，‘次’版本每次发布递增。对于任何回溯修复，补丁版本号将递增。
例如，2026 年的第一个版本将是
v2026.0，下一个是v2026.1，依此类推。发布将获得两个完整发布周期的关键修复。例如，
2026.0的支持将持续到发布2026.2。 -
大约每 6 个月，将其中一个发布声明为长期支持发布 (ESR)。ESR 版本在下一个 ESR 声明后仍受支持两个发布周期。
例如，如果 v2026.0 是 ESR，v2026.6 是下一个 ESR，那么 v2026.0 的支持将在 v2026.8 发布时结束。假设每月一次的节奏，这将是 ESR 支持的 2 个月重叠。
-
为
latest、最新发布、前一个发布和任何活动的 ESR 版本提供关键修复。 -
将
tests-passed分支重命名为latest。
一年中支持周期的示例图：
gantt
title Discourse 发布和支持周期 (2026 年 1 月 – 2027 年 1 月)
dateFormat YYYY-MM-DD
axisFormat %b %Y
2026.0 (ESR) :active, 2026-01-27, 2026-09-29
2026.1 :done, 2026-02-24, 2026-04-28
2026.2 :done, 2026-03-31, 2026-05-26
2026.3 :done, 2026-04-28, 2026-06-30
2026.4 :done, 2026-05-26, 2026-07-28
2026.5 :done, 2026-06-30, 2026-08-25
2026.6 (ESR) :active, 2026-07-28, 2027-01-26
2026.7 :done, 2026-08-25, 2026-10-27
2026.8 :done, 2026-09-29, 2026-11-24
2026.9 :done, 2026-10-27, 2026-12-29
2026.10 :done, 2026-11-24, 2027-01-26
2026.11 :done, 2026-12-29, 2027-01-26
实施
-
每个发布都将有一个从
latest切出的分支。这些分支将被命名空间并永久保留。例如，v2026.1将有一个名为release/2026.1的分支。 -
每个补丁发布都将被标记。例如
v2026.1.0、v2026.1.1等。 -
最新发布将被标记为
release。最新的 ESR 将被标记为esr。 -
前一个发布将被标记为
release-previous。前一个活动的 ESR（如果有）将被标记为esr-previous。 -
为了向后兼容，与现有发布流匹配的标签将被别名化为最接近的新等效项。
stable→esr。beta→release。tests-passed→latest。这些将被视为已弃用，我们将致力于在未来删除其中一些或全部。特别是，“beta”是有问题的，因为它给人一种 Discourse 未准备好生产的印象。
-
在
latest上，版本号将是当前正在开发的版本，后缀为-latest。例如2026.3.0-latest。
自动化发布流程
每月，一个 GitHub action 将打开一个新的 PR，其中包含一个将 main 上的 version.rb 提升到下一个 -latest 版本的提交。
一旦有人合并了 PR，另一个 GitHub action 将检测到 main 已更新到下一个 -latest 版本，并为已完成的发布创建一个分支。本质上，这个分支将成为一个“发布候选”。另一个自动化 PR 将针对发布分支打开，更新 version.rb 以删除 -latest 后缀，从而“发布”它。
通常，我们会快速连续合并这两个 PR。但是，将创建和最终发布分开的 PR 使我们有机会在最终确定之前解决分支中的任何问题。
%%{init: { 'logLevel': 'debug', 'gitGraph': {'showBranches': true, 'showCommitLabel':true,'mainBranchOrder': 2}} }%%
gitGraph
checkout main
commit id:'version v2026.1-latest'
commit id:'...'
commit id:'....'
branch 'release/2026.1'
commit id:'version 2026.1'
checkout 'main'
commit id:'version v2026.2-latest'
另外，另一个 GitHub actions 工作流将监视发布分支上的任何回溯提交。当找到任何提交时，将生成一个新的 PR 来提升该分支上的补丁版本。人工可以决定何时合并这些 PR。
所有这些自动化都将自动保持各种标签（release、release-previous、esr、esr-previous，以及向后兼容的别名）的最新状态。
安全修复
安全修复工作流程基本保持不变，只是我们现在需要在以下三个新位置中的两个位置进行修复：
-
latest -
esr -
esr-previous
-
release -
release-previous
（请记住，根据之前的图示，只需要三个中的两个，因为 esr-previous 是受支持的，新的 esr 与 release 或 release-previous 相同，并且在不再适用时我们将停止支持 esr-previous）。
在将安全修复引入 latest 时，latest-security-fix 标签将自动移至该提交。docker_manager 将被更新以监视该标签并提示管理员进行更新。这使我们能够在不需要加速版本升级的情况下发布和通知安全修复。
翻译
目前，stable 和 tests-passed 分支可以在 CrowdIn 中进行翻译，并且结果会定期集成。在新系统中，我们最初计划让 latest 和 release 在 CrowdIn 中进行翻译。
理想情况下，当 release 变为 release-previous 或 esr 时，翻译将已稳定。如果对这些版本的持续翻译有需求，那么这将在未来可以考虑。
插件/主题兼容性
增加使用非 latest Discourse 流的频率将增加我们对 discourse-compatibility 系统的依赖。因此，我们需要对兼容性系统进行一些改进。
我们可以使用特殊命名的分支/标签来支持隐式兼容性，而不是在 main 上使用 .discourse-compatibility 文件。这应该比手动处理提交哈希更容易。例如，一个插件可以有如下分支：
d-compat/v2026.1d-compat/v2026.2d-compat/v2026.3main（用于任何没有自己分支的 Discourse 版本）
安装插件时，Discourse 可以检查是否存在与当前版本匹配的分支。如果存在，则检出该分支。否则，检查 .discourse-compatibility 文件。否则，检出默认分支。
我们可以创建一个公共 GitHub action，该 action 每天在每个主题/插件上运行，检查新的 Discourse 版本，并自动创建这些分支。每个主题/插件可以选择使用此自动固定操作，或者选择更“浮动”的策略。
discourse.org 托管
最初，我们的托管服务将继续运行最新版本的 Discourse。未来，我们将探索为我们的企业级客户选择“发布”版本的选项。
标准安装默认值
最初，默认值仍将是 latest。管理员将能够选择加入新的发布流，就像他们目前选择加入 stable 一样。一旦系统更加成熟，我们可能会在未来探索在发布流之间进行更轻松的切换。
这是一个伟大的进步！
。然而，在我喝了第三杯酒之后，你决定发布 v2026.4，我的客户决定更新。然后，“砰”的一声，我的插件里没有 v2026.4 分支，功能也消失了 
。
