好的，但我认为我对此问题理解得更少了 
归根结底，正如 @david 的最新评论所述，这并不重要，所以只是总结一下。
建议的模型是每月发布一次，外加 2 个 esr 版本，例如 2026 年：
所以假设我们在 2026 年 10 月，并且 .2 和 .8 是 esr 版本，这意味着有 4 个受支持的版本。
我的想法是。是否可以更容易地实现季度发布，即 2026 年：
并且仍然只支持当前版本和上一个版本，所以在 2026 年 10 月，将是 2 个版本。
整个推理是，这也许会让开发人员和用户都更容易。但如上所述：@david 已澄清，不那么频繁的发布不是一个选项。
明白了。这大致符合我的预期。确实，在这种情况下，至少在中期有一些工具支持会很好。
我的设想是：你处于一个特定的发布频道（最新、发布、esr），并且通常你会相对较快地迁移到下一个版本，所以当新版本可用时收到消息和/或通知，并有一个切换到它的单一命令会很方便。对于那些推迟采用新版本的用户，当当前使用的版本变得过时/不受支持时，也能收到提醒会很好。如果相应的工具还能让你快速切换发布频道，那就更好了 
但我理解如果现在这不是首要任务，并且你仍然建议人们停留在测试通过/最新版本。
我明白了。在我工作的情况下，将功能发布给客户被认为是“快速” 
另外，如上所述，我的想法是转向季度计划实际上会让你的工作（以及插件/主题开发者的工作）更容易，因为需要维护的分支更少。所以如果情况并非如此，那么我猜这确实对你没有意义
我不认为你提出的这种基于年份的版本控制方案有什么好处。请坚持使用符合 SemVer 的版本号！
SemVer 本身并不是为大型应用程序设计的。我的理解是，它更多地针对被软件使用的库，特别是版本编号逻辑围绕包的 API 构建。
不过，我们可以将 SemVer 应用于我们的 API。围绕 Discourse 暴露的 API 拥有更强的保证绝对是一个值得进行的讨论，但我认为这与当前的话题是分开的。
现在，我明白你并没有说我们应该符合 SemVer——你只是说我们应该坚持使用符合 SemVer 指定的编号系统的_数字_。
- 普通版本号必须采用 X.Y.Z 的形式，其中 X、Y 和 Z 是非负整数，并且不得包含前导零。X 是主版本号，Y 是次版本号，Z 是补丁版本号。每个元素必须在数值上递增。例如：1.9.0 → 1.10.0 → 1.11.0。
我认为如果我们选择这条路线，唯一会违反的就是“前导零”的建议。
否则，我认为任何 SemVer 库仍然能够解析我们建议的版本号并正确地对它们进行排序。
撇开这些不谈，你能否分享更多关于你为什么认为符合 SemVer 编号系统有价值的看法？
如果我理解正确的话，OP（楼主）说你们没有使用前导零。
我认为，使用前导零（按版本排序）的一个令人信服的理由也已被提出。前导零是目前的计划吗？（我仍然喜欢按月版本而不是序列版本）。
SemVer 的要点是版本号应传达一些有用的信息。您提出的方案所传达的唯一信息是地球绕太阳的公转。这些信息对软件的消费者来说并没有多大用处。
如果出于某种原因我确实想知道发布日期，我会查看发布信息并获取完整日期。
并非如此。关键在于向用户传达发布的性质。
如果发布是补丁版本号的增加，这表明更改集不包含任何可能影响软件用户工作流程的内容。
如果发布是次要版本号的增加，这表明更改集包含新的面向用户的组件，但不会破坏软件用户的现有工作流程。
如果发布是主要版本号的增加，这表明更改集包含可能破坏软件用户现有工作流程的更改。
对于具有单一用户界面的软件产品，确定应增加哪个版本组件更为明确，但即使对于像 Discourse 这样具有各种级别界面和消费者类型（例如插件开发人员、API 消费者、论坛员工、最终用户）的软件产品，其原则也保持不变。
即使在这个软件项目中，选择增加哪个组件可能有点主观，但它仍然使版本号具有意义，而不是像您的提议那样仅仅是一个任意的数字。
我在上面的几个帖子中也提出了这一点。
与 semver 相反，提议的版本号方案可以立即清楚一个版本是否仍然受支持（例如 Ubuntu）。由于这还取决于地球绕太阳的轨道，所以这实际上是有意义的。
这显然是针对软件包和库的。任何 Discourse 发布都包含可能破坏软件用户现有工作流程的更改。我甚至见过安全补丁这样做。Semver 不适用于复杂的应用程序。
是的，确实如此，参见
一旦您确定了您的公共 API，您就可以通过对版本号进行特定增量来传达对其的更改。
为了强调一个可能被忽略的观点，我认为 Discourse 在这方面做得很好。一个改进是至少突出显示您已经写过的、描述了在该升级周期内进行的更改和潜在中断的主题。例如，对于 3.5 版本，我必须打开发行说明，点击进入博客，然后碰巧点击关于将插件与 Discourse 核心捆绑的链接，才能了解到将这些插件保留在我的配置文件中可能会影响升级的详细信息。
最好能将这些类型的说明提取到一个页面/主题中，用于 ESR 版本，即使它只是一个指向在执行 ESR 升级之前应审查的现有主题的链接集。
不过，这可能超出了此线程的范围——我对版本更改的反馈是，我欢迎它，并赞赏这里的透明度。我认为这将是一个伟大的改进，可以简化事情，同时为我们提供更多自托管的选项。
谢谢！
是的，而且这个主意太好了，我认为应该编辑帖子以反映这一点！
正在考虑前导零以及是否更明确地争取与月份同步。@david 一旦负责此事的团队做出决定，就会分享更新。
对于评估新版本的论坛维护者来说，这并不是重要的信息。
不，真的。你通过拒绝理解“API”实际上仅仅意味着接口，而错过了 SemVer 的真正要点。没有任何理由说明 SemVer 的精神不能用于任何类型软件的版本控制。
我认为我们在这个问题上只能各持己见，@per1234。
这是在 semver 的 GitHub 存储库上进行的一次相关讨论，其中一位维护者对此做出了回应：
Semver 对于“最终用户应用程序”来说并不是真正有用，它对于人们用作项目依赖项的库更有用。
无论是库还是大型应用程序，这都没有太大关系。语义化版本控制方案对大型应用程序来说非常适用。它甚至可以用于捆绑成一个平台的应用程序集合，但在这里，它会变得相当难以处理。
主要问题在于，你是否会采取在一个版本中支持弃用，而只在下一个主版本中移除它的路线。拥有已弃用但受支持的功能可能会花费相当多的精力。当你将要更改持久化数据模型时，弃用通常会变得不可能。如果发生这种情况，你甚至不能进行带有弃用功能的次要版本更新，并且会立即跳转到下一个主版本。这正是大型应用程序通常遇到的问题。你从 3.0.0 变为 3.0.1 再变为 4.0.0，因为你无法提供向后兼容性。如果你经常有破坏性更改，坚持使用 semver 的价值很小。
话虽如此，我更喜欢这种结构，因为它能更清晰地向开发人员传达将会有破坏性更改。YYYY.N 方案对我这个开发者来说毫无意义，对我这个管理员来说也毫无意义。
那么问题是，你想通过版本传达什么？如果你想进行 6 次功能发布（可能包含破坏性更改，也可能不包含），并且每第 6 次发布将获得更长的补丁支持；并且你不想为补丁发布进行版本控制。那么 X.Y 是一个合适的方案，其中 Y=0 是获得更长支持的版本。X 只是一个数字。问题在于，当 X 是年份时，Y 很快就会与月份相关联。那么更新的、获得更长支持的版本将在 1 月发布？我总是不得不查找哪个 Ubuntu 版本是 LTS 版本，这让我很烦恼。
那么，如果 Discourse 只是继续使用当前的主版本呢？下一个获得更长支持的版本称为 4.0；然后我们得到 4.1 到 4.5 作为功能发布；之后是 5.0，这是最新的、获得更长支持的版本。
这样，你就不会遇到因重大问题而导致发布延迟的尴尬时刻。
你可以选择添加一个“补丁”号，如果你计划明确发布补丁（而不是进行滚动补丁发布）。“但那样就有 x.y.z，这看起来像 semver”。嗯，不是的，它看起来像 semver，但实际上不是。每一个新的“次要”版本都可能是破坏性的。所以我建议只坚持使用 X.Y 作为版本方案，其中 Y=0 表示 LTS。
版本字符串暂且不论。我确实喜欢新的发布计划。
是的，这基本上就是我们今天的现状，尤其是有了灵活的主题系统。
所以我认为你在这里说得很对：
这也意味着我们当前版本号的“主要”部分几乎没有传达任何信息。
所以，感觉就像“嘿，既然如此，不如用年份来传达_一些东西_。”
这场讨论看起来不太好。我看到开发团队决定采用一个对他们来说有意义的新版本控制系统，而另一些人则突然认为 Discourse 版本遵循语义化版本控制……但事实并非如此。至少自 1.0 版本以来，它一直是一个滚动发布版本，或者不是？
但辩论各方的论点似乎都有缺陷：
我看到的主要变化是，通过采用每月发布一次的节奏，Discourse 团队正在设定期望，并从发布目标转向拥抱定期发布。
LTS（长期支持）8 个月听起来并不“长”。NodeJS 的发展速度太快，但它们仍然保持 30 个月以上的 LTS 支持，并且同时支持几个当前版本，而 Ubuntu 则将 LTS 支持延长数年。虽然我明白 Discourse 既不是一门语言也不是一个操作系统，但它似乎预示着新功能将以相当快的速度发布，这又引出了另一个问题：由于时不时会引入新的管理员设置，我们很快就会陷入 WordPress 的困境，拥有无限的选项和令人费解的站点管理复杂性，即臃肿软件：那么，弄清楚如何从具有目标的现有版本迁移到定期发布，以及如何选择要为发布放弃（或推迟）哪些目标等，就变得很重要（这可能已经记录在案，但我错过了）。
您能否分享一下您在开发节奏/版本控制之间的理由，以及您打算如何避免管理员在过多的设置和陡峭的学习曲线下淹没？
在回答您的其他问题之前，我想首先澄清，我们建议的发布频率不会因这项提案而改变。
在此新提案中，我们打算保持与之前相同的发布节奏，主要变化如下：
考虑到这些，您是否觉得您关于设置过多的其他问题仍然与此提案相关？或者它们是独立的问题，最好在单独的主题中讨论？
感谢您@mcwumbly的详细解释！
确实，这是一个不同的问题。使用插件自定义管理员将有助于测试其可能的外观。关于这种方法是否有任何正在进行的工作？
并非专门针对此，但我们在过去一年中投入了相当多的精力来改进管理员界面。如果您想更深入地研究这些问题，可以开启一个新主题，并阐述您想进一步讨论的一些问题和/或想法？
这是一个伟大的改变（我特别喜欢重叠的 ESR）
反馈：
我希望将生命周期图表放在一个集中的页面上，以便轻松查看，最好附带一个 EOL 表格，这样我就可以轻松地知道在任何给定时间哪些处于支持中，哪些已超出支持范围，并据此进行规划（至少对于 ESR）。
流切换：
这将是很好的——但即使只是在设置过程中选择一个标签也会有很大帮助。或者甚至只是在设置文档中包含手动步骤。如果有人想从 stable/ESR 开始，现在对新管理员来说，如何做到这一点并不清楚。（我认为答案是通过 --skip-rebuild 传递给 ./launcher，然后编辑版本，然后第一次进行重建，但我不太确定。）因为否则设置将立即开始获取并运行最新版本，然后回滚会带来麻烦。
（对新管理员来说的难度示例：目前，“install discourse stable”的搜索结果排名第一的是这个帖子，它链接到另一个解释如何升级到 stable 的帖子，但没有说明如何从头开始安装 stable。）
今天我们在实施此 RFC 方面又迈出了一步——最新版本的 Discourse 编号为 v2025.11.0 