我之前不知道 discourse-compatability，所以需要对此进行一些了解。
我想就此发表看法，因为这似乎表明 Discourse 团队对 stable 的看法与 Discourse 社区/更广泛的论坛管理员社区对 Discourse 的 stable 产品提供的看法之间存在巨大脱节。
Stable 不符合 LTS 定义的关键原因。
1) 工作人员在提到 stable 时，会积极劝阻使用它。
我不一定想点名个别发帖人，但这里有一系列来自工作人员的帖子，以展示这种趋势：
请注意，在某些方面，
tests-passed比stable更稳定，因为它是 discourse.org 运行的版本，因此经过了最佳测试。
因此，Discourse 处于永久 beta 状态，这意味着我们一直在开发新功能和进行改进。在我们的案例中，beta 并不意味着不稳定；我们在 tests-passed 和 beta 版本上托管了每月数百万次页面浏览量的网站。
stable 通道不一定比 tests-passed 更“稳定”。它更多的是关于已知 bug 的概念，并且作为一组特定功能和改进的检查点。对于 tests-passed，可能会引入新 bug，然后在几个提交后修复。
信息一直很一致，即 Discourse 处于“永久 beta”状态，这并不是生产环境/非开发用户想要获得的体验。
在快速搜索 discourse stable 的前十个链接时，似乎没有一个真正支持使用 stable。因此，无论其实际质量如何，如果工作人员普遍引导人们远离 stable，那么它在人们心中就会留下不适合生产环境的负面印象。
stable 可能很棒，但如果我们一遍又一遍地被告知最好不要使用它，我们就不会考虑将其用于严肃的部署。
2. LTS 除了安全 bug 修复外，还会收到 bug 修复。
LTS 是一个不接收功能升级但会接收 bug 修复的版本。根据工作人员自己的评论，在 Discourse 中似乎没有努力将非安全问题的 bug 修复反向移植。也许事实并非如此，但这是我们被告知的。
3. LTS 具有简单的安装步骤。
安装指南甚至没有提到 stable 的存在。
4. LTS 被广泛使用。
在您发帖之前，我从未听说过 stable 分支被广泛使用。它在野外也被广泛使用吗？鉴于它的隐藏程度，我对此表示怀疑，但我没有相关数据。这是因为这能让人们有信心在生产部署中使用 stable，所以这是一个重要因素。
5. LTS 具有清晰的发布周期和升级说明。
我没有看到任何明确记录 stable 的中心位置。（可能是我错过了！）
我对 LTS 的期望是一个页面，其中包含：
- 当前活跃的发布版本
- 发布说明，包括：
- LTS 版本之间主要更改/功能
- 从过去 LTS 版本迁移的步骤（特别是需要注意的重大更改）
- 每个版本的计划活跃支持长度
例如：mediawiki，但实际上任何主要的开源 LTS 都有类似的页面。
这些文档可以帮助我规划何时会出现需要停机和/或手动干预的重大更改。
6. LTS 在一个发布周期内没有重大的破坏性更改。
这很可能就是 stable 的情况，但我太习惯于点击升级按钮然后论坛就崩溃了，所以不确定。我想在这里寻找的是在版本之间出现破坏性更改时更明确的警告。
7. LTS 提供至少一个完整 LTS 发布周期的 API 弃用警告。
这些应该以一年以上为单位来衡量，而不是一个月以上。
8. LTS 是分阶段的/有重叠的支持期。
任何大型 LTS 都将有两个 LTS 版本之间的重叠支持期。Stable 似乎只是进行二元切换到下一个版本。（由于没有中心文档页面，我的印象也可能出错）
9. 从非 LTS 升级到 LTS 很简单。
无需支持回滚，但当 LTS 可用时，尚不清楚如何干净地将分支切换到 LTS。看起来论坛上有一些关于此的帖子，但同样，我找不到任何集中的文档。
我喜欢 Discourse，但这既是我遇到的一个常见痛点，也是许多其他人遇到的痛点。stable 目前只是一个分支，而不是一个 LTS。