我不知道“已验证”是否有正式定义。
所有软件都可能存在 bug。
tests-passed 包含最新的提交。beta 只接收 beta 版本。stable 只接收稳定版本。
tests-passed 是 discourse.org 托管的几乎所有站点以及绝大多数自托管站点上运行的版本。
@mcwumbly – 我们有“应该运行哪个版本”的文档吗？我搜索了一下，没找到。我只记得在 stable 版本公告中看到过类似这样的内容。
5 个赞
有
也许这可以作为主题的一个好开端
5 个赞
此帖子也在此处引用：Is Discourse always in "beta"?
我们还有这个主题：Configure a supported tracking branch to get Discourse software updates
同意我们应该有一个关于此事的更好主题，以便我们可以更清楚地引用我们关于使用 tests-passed 的建议。
另外，我有点想去掉 beta（我可能会就此开启一个新主题）。
6 个赞
我们还应该在安装说明 discourse/docs/INSTALL-cloud.md at main · discourse/discourse · GitHub 中解释不同构建版本之间的区别以及如何更改您正在使用的构建版本。我刚看了看，没有看到任何提及。
3 个赞
我将这部分内容分开了（我想这是我第一次这样做！），因为可怜的人仍然无法判断升级是否“危险”，而关于如何解决人们不知道是否升级的问题的讨论并没有帮助。
事实上，Updates always come before release notes - #7 by jomaxro 是一个很好的开始，或者也许只需要这个。给它一个自己合理的标题。
但是等等！
也许 Is Discourse always in "beta"? 正是我想要的（但我忘了它在那里，所以没找到）。
他问的另一件事，也是他开始的地方，我认为是相当合理的，那就是“如果我在最新的测试版上，为什么还需要升级？”而上面直接解决了这个问题。
答案出奇地复杂。
太棒了。我的工作完成了。 
6 个赞
我认为我们不应该这样做。我们希望人们使用 tests-passed。官方安装说明应导致默认安装，其中包含尽可能多的我们想要的设置。这包括跟踪的分支。
5 个赞
总会有人想使用例如最新的稳定版本。不在最显眼的地方提供如何实现这一点的指南，并不会让这些人消失；只会让他们稍微不方便一些——而且很可能有时会让他们来这里提问，而其他人则花费时间（一遍又一遍地）回答问题。
然而，更有力的论点可能是，该指南可以向他们展示如何正确地进行操作，这意味着如果他们改变主意，以后可以轻松地改回。如果他们不知道，他们可能会弄坏自己的安装，这对他们和他们的社区来说都会很不方便。
如果 INSTALL-cloud.md 有一个关于更改分支的部分，它可以阐明默认分支是什么以及为什么，从而清楚地表明默认分支是最广泛使用的，也是最容易支持的。
我完全赞成在 Meta 上发布关于如何更改分支的指南。我只是不认为它应该放在官方安装指南中，因为 95% 的人并不关心或不需要关心。
如果“基础鲍勃”正在尝试安装 Discourse，他只想尽快轻松地完成安装，以便他可以开始处理他的新网站。有关更改分支的信息只会让他思考更多，并造成混淆。
另一方面，“高级艾莉”可能对了解分支的工作原理以及哪个分支最适合她的网站感兴趣。但她也很可能在安装 Discourse 之前进行更多研究，而不仅仅是浏览安装指南。
6 个赞
确实，就像现在一样，我们会偶尔收到用户想要回滚到 beta 或 stable 版本但失败的主题。
将其放入标准安装文档将真正打开闸门，这既是因为上述原因，也是因为与旧版本相关的插件兼容性问题。
4 个赞
我同意。总的来说，我觉得 beta 带来的困惑比它提供的效用更多。
我认为区分那些你使用且有内部意义的事物与那些对第三方有意义的事物很重要。beta 分支就是一个很好的例子。虽然它可能有一些内部效用，但对第三方几乎没有效用，有时还会让他们感到困惑。
我很想听听不同的意见，但现在想想，我不记得有任何认真的自托管用户以任何有意义的方式使用过 beta。“普通鲍勃”其实不知道什么是分支，可能也不在乎（这很正常）。“高级艾莉”如果是个人或中小企业，会使用 tests-passed，如果是中大型企业，可能会使用 stable（或固定提交）。
我的建议是，在分支方面保持现状，但公开说明“我们有两个分支供您使用：tests-passed（默认且最佳）和 stable（如果您知道自己在做什么并且有特定需求）”。
6 个赞
对我来说，仅在仪表板上看到 tests-passed 分支名称而不是版本名称就足够了。
完全同意。任何想要使用不同分支的人几乎总能找到它。
如果他们无法通过现有资源（搜索、标准 GitHub 项目）找到它，那么他们是否真的具备完全理解分支之间差异的技能，更不用说偏离默认的安全性了？
2 个赞
当然，这很有道理。但我觉得我们错失了一个帮助人们理解不同选项之间区别的机会。我看不出告诉自托管者默认是 tests-passed 有什么坏处，这对大多数网站来说是理想的，并确保您获得最新的安全修复和更新。如果您规避风险，可以将其保留为 tests-passed，并在软件提示您时或在收到提示一周左右后进行更新。这样，其他人会先发现任何问题，并在您更新之前得到修复。
鉴于以上情况，自托管者是否有正当理由从 tests-passed 切换？我想，如果您的网站经过大量修改，并且在核心 discourse 或官方插件更新时会中断，而您不信任自己或您的管理员进行更新？或者您正在设置开发或暂存环境？
另一个可以解释这一点的地方是在 app.yml 中，它目前相当晦涩，因为它只引用 tests-passed 而没有提及选项或何时切换到另一个选项。
## 这个容器应该使用哪个 Git 版本？ (默认值: tests-passed)
#version: tests-passed
1 个赞
在我看来，除了 tests-passed 之外，使用其他任何东西只有在你使用托管服务或：1）你的社区有团队管理（即你是中大型企业）；以及 2）你有特定原因不使用 tests-passed，例如你有多个可能中断的自定义设置。
我认为这两个条件都是必需的，因为除非你的社区有团队管理，否则在多个脆弱的自定义设置场景下，你的问题不是分支使用问题，而是你的整体网站管理问题（即不可持续）。
即使两者都成立，也还有其他因素需要首先考虑，例如你的更新策略。
我认为问题在于，如果你说“你可以使用 stable 或 tests-passed”，有些人会因为听起来“明智”而将 stable 放入其中，尽管他们可能不应该使用它。
Beta 分支何去何从？
为了进一步论证反对 beta 分支的理由，在各种书面和口头语境中，它产生的主要混淆在于：
-
人们通常将“beta”一词与比“standard”更前沿的东西联系起来。在这里并非如此。
-
一些企业考虑使用它，因为它似乎比 tests-passed 稍微不那么前沿，又比 stable 更新一些，即它看起来“明智”。但在大多数情况下，这不是一个好主意。
-
“beta”既是 Discourse 版本号中使用的术语，也是 Discourse 分支的名称。我发现这会让一些人感到困惑。
7 个赞
“Beta”可能会让一些像我一样半懂电脑的人望而却步——通常的意思是“仍在测试质量”，而不是“仍在添加功能”。
我想我主要考虑的是版本名称，而不是分支名称。我曾假设我处于一个“beta”分支，基于版本名称（我不是），直到现在才检查，所以这一切都没有让我望而却步……
2 个赞
是的。我认为这令人困惑（或者我可以看到它可能令人困惑），即您处于 tests-passed 状态，版本显示为“beta”，但您可以进行升级并获得与您已有的 beta 版本相同的新代码。而且 beta 版本之间有数周和数百次提交。
5 个赞
我已经对本指南进行了一些编辑，以整合上述讨论和参考资料：Configure a supported tracking branch to get Discourse software updates
3 个赞