这场讨论看起来不太好。我看到开发团队决定采用一个对他们来说有意义的新版本控制系统，而另一些人则突然认为 Discourse 版本遵循语义化版本控制……但事实并非如此。至少自 1.0 版本以来，它一直是一个滚动发布版本，或者不是？
但辩论各方的论点似乎都有缺陷：
- “行业标准”：Linux 使用偶数主版本号用于稳定版，奇数主版本号用于开发版。
- “地球绕太阳公转”：好吧，如果你皈依伊斯兰教，你就会遇到麻烦，因为你将放弃版本号，而且它将不再与太阳的公转相匹配，而是与月亮的周期相匹配。在这里，你现在明白，通过选择 YYYY.Y.Z 版本控制方案而不是 X.Y.Z，你强制了一种主流文化。
- 次要版本发布仍然不清楚：你提到“假设每月发布一次”，但它也可能是 3 周或 7 周，取决于功能，在这种情况下，从 0 开始计数 Y 是有意义的，或者你实际上打算每月发布一次，在这种情况下，从 1 开始计数 M 会更有意义？
我看到的主要变化是，通过采用每月发布一次的节奏，Discourse 团队正在设定期望，并从发布目标转向拥抱定期发布。
LTS（长期支持）8 个月听起来并不“长”。NodeJS 的发展速度太快，但它们仍然保持 30 个月以上的 LTS 支持，并且同时支持几个当前版本，而 Ubuntu 则将 LTS 支持延长数年。虽然我明白 Discourse 既不是一门语言也不是一个操作系统，但它似乎预示着新功能将以相当快的速度发布，这又引出了另一个问题：由于时不时会引入新的管理员设置，我们很快就会陷入 WordPress 的困境，拥有无限的选项和令人费解的站点管理复杂性，即臃肿软件：那么，弄清楚如何从具有目标的现有版本迁移到定期发布，以及如何选择要为发布放弃（或推迟）哪些目标等，就变得很重要（这可能已经记录在案，但我错过了）。
您能否分享一下您在开发节奏/版本控制之间的理由，以及您打算如何避免管理员在过多的设置和陡峭的学习曲线下淹没？
