「検証済み」という正式な定義は、私の知る限りありません。
すべてのソフトウェアには、潜在的なバグがあります。
tests-passed は最も最新のコミットが含まれています。beta はベータ版リリースのみを受け取ります。stable は安定版リリースのみを受け取ります。
tests-passed は、virtually all discourse.org でホストされているサイトや、大多数のセルフホストサイトで実行されているものです。
@mcwumbly – 「どのバージョンを実行すべきか」というドキュメントはありますか？少し検索しましたが、見つかりませんでした。stable の発表から覚えているのは、このようなことだけです。
There is
トピックの開始点として良いかもしれません
この投稿は、こちらもここで引用されています: Is Discourse always in "beta"?
そして、このトピックがあります: Configure a supported tracking branch to get Discourse software updates
tests-passed を使用することを明確に参照できる、より良いトピックを持つべきであるということに同意します。
別件ですが、beta を廃止したい誘惑に駆られています（それについては新しいトピックを開始するかもしれません）。
インストール手順の GitHub - discourse/discourse: A platform for community discussion. Free, open, simple. விக்கி/INSTALL-cloud.md で、ビルドの違いと、現在使用しているビルドを変更する方法についても説明すべきです。ざっと確認しましたが、それに関する言及は見当たりませんでした。
これを（初めてやったと思いますが！）分割しました。というのも、その人はまだアップグレードが「危険」かどうか判断できず、アップグレードすべきかどうかを知らないという問題の解決策についての議論は役立っていません。
実際、Updates always come before release notes - #7 by jomaxro は良い出発点ですが、もしかしたらそれだけで十分かもしれません。適切なタイトルを付けるだけです。
もしかしたら、探していたのは Is Discourse always in "beta"? かもしれません（探すためにそこにあったことを忘れていました）。
彼が尋ねたもう一つのこと、そしてそれが始まった場所であり、非常に合理的だと思いますが、「最新のベータ版を使用している場合、なぜアップグレードが必要なのですか？」ということです。そして上記はそれをかなり直接的に扱っています。
答えは驚くほど複雑です。
素晴らしい。私の仕事は終わりました。 
そうすべきではないと思います。私たちは人々が tests-passed を使用することを望んでいます。公式のインストール手順は、私たちが望む設定ができるだけ多く一致するデフォルトのインストールにつながるべきです。それには、追跡されるブランチも含まれます。
最新の安定版リリースを使用したいと考える人が常にいるでしょう。最もわかりやすい場所にその方法を示すガイドがないからといって、そのような人がいなくなるわけではありません。ただ、彼らにとって少し不便になるだけです。そして、おそらく彼らがここに来て質問し、他の人が（何度も）回答に時間を費やすことになるでしょう。
しかし、より強力な議論は、ガイドが彼らに正しく行う方法を示すことができるということです。つまり、気が変わったときに元に戻すことができるということです。もし彼らが知らなければ、インストールを壊してしまう可能性があり、それは彼らとコミュニティの両方にとって不便になります。
INSTALL-cloud.md にブランチを変更するセクションがあれば、デフォルトが何であり、なぜそうなのかを明確にすることができます。デフォルトが最も広く使用されており、サポートが最も容易であることを明確にすることができます。
Metaにブランチの変更方法に関するガイドがあっても、私は100%賛成です。ただ、それが公式のインストールガイドに載るべきではないと思います。なぜなら、95%の人は気にする必要がないからです。
もしBasic BobがDiscourseをインストールしようとしているなら、彼は新しいサイトで作業できるように、できるだけ早く、そして簡単にインストールを完了させたいだけです。ブランチの変更に関する情報は、彼に余計なことを考えさせ、混乱させるだけでしょう。
一方、Advanced Allyは、ブランチがどのように機能するか、そして自分のサイトに最適なブランチはどれかについて理解することに興味があるかもしれません。しかし、彼女はDiscourseのインストールガイドをただ実行するのではなく、インストール前にさらに多くのリサーチをしている可能性が高いです。
実際、現状でも、ユーザーがベータ版または安定版へのロールバックを希望し、それが失敗するというトピックが時折発生しています。
標準のインストールドキュメントにそれを記載すると、上記の理由と古いリリースでのプラグインの互換性の問題の両方から、問題が大量に発生することになるでしょう。
私も同感です。全体的に見て、beta は有用性を満たすというよりも、人々を混乱させる原因になっていると感じています。
内部で意味を持ち、使用するもののうち、サードパーティにとって意味を持つものとの間に区別を設けることが役立つと思います。beta ブランチはその良い例です。内部的な有用性があるかもしれませんが、サードパーティにとってはほとんど有用性がなく、時には混乱させることもあります。
他に意見があれば聞きたいですが、今考えてみると、beta を意味のある方法で使用している真面目なセルフホスティングユーザーを思い出すことができません。「ベーシックボブ」はブランチが何であるかを実際には知らないし、おそらく気にもしないでしょう（それはそれで構いません）。「アドバンスドアリー」は、個人または中小企業であれば tests-passed を使用し、中規模または大規模企業であれば stable を使用するか（またはコミットをピン留めする）でしょう。
私の提案は、ブランチに関してはすべて現状維持のまま、公開的には「使用できるブランチは2つあります：tests-passed（デフォルトで最高）と stable（何か特別なニーズがあり、その方法を知っている場合）」と言うことです。
こちらからは、ダッシュボードのバージョン名の横に tests-passed というブランチ名が表示されるだけで十分改善されます。
全く同感です。別のブランチを使いたい人は、ほとんどの場合それを見つけることができます。
既存のリソース（検索、標準的なGitHubプロジェクト）で見つけられない場合、デフォルトの安全策から逸脱することは言うまでもなく、ブランチ間の違いを完全に理解するために必要なスキルを持っているのでしょうか？
確かに、それは理にかなっています。しかし、ここでさまざまなオプションの違いを理解する機会を逃しているように感じます。セルフホスティングしている人に、デフォルトはほとんどのサイトに理想的で、最新のセキュリティ修正とアップデートを確実に取得できる tests-passed であると伝えることに害はないと思います。リスク回避型の場合は、tests-passed のままにして、ソフトウェアでプロンプトが表示されたとき、またはプロンプトが表示されてから1週間ほど後にのみ更新できます。そうすれば、他の人が最初に問題を発見し、更新する前に修正されます。
上記を考慮すると、セルフホスティングしている人が tests-passed から切り替える正当な理由は何でしょうか？おそらく、サイトが大幅に改造されており、コアの Discourse や公式プラグインが更新された場合に壊れる場合で、更新しないことを自分自身または管理者を信頼していない場合でしょうか？または、開発またはステージング環境をセットアップしている場合でしょうか？
これを説明するもう 1 つの場所は app.yml です。これは現在、tests-passed にしか言及しておらず、オプションや別のオプションに切り替える時期については言及していないため、かなり不可解です。
## このコンテナはどの Git リビジョンを使用しますか？ (デフォルト: tests-passed)
#version: tests-passed
私の意見では、tests-passed 以外を使用することは、マネージドホスティングサービスを利用している場合、または次のいずれかの場合にのみ意味があります。1) コミュニティを管理するチームがいる場合（つまり、中規模から大規模な企業である場合）。そして 2) tests-passed を使用しない特定の理由がある場合。たとえば、複数のカスタマイズが壊れる可能性がある場合などです。
両方の条件が必要だと考えます。なぜなら、複数の壊れやすいカスタマイズのシナリオでコミュニティを管理するチームがいない限り、問題はブランチの使用ではなく、サイト全体の管理（つまり、持続可能ではない）だからです。
両方が真実であっても、更新ポリシーなど、まず考慮すべき他の事項があります。
「stable または tests-passed を使用できます」のようなことを言うと、一部の人は「sensible」に聞こえるからという理由で stable を指定するでしょうが、実際にはそれを使用すべきではない可能性が高い、というのが問題だと思います。
beta ブランチに対する議論をさらに進めるために、さまざまな書面および口頭の文脈で、それが引き起こす主な混乱は次のとおりです。
人々は通常、「beta」という言葉を「standard」よりもさらに最先端のものと関連付けます。ここではそうではありません。
一部の企業は、tests-passed よりも少し最先端ではなく、stable よりも少し最新であるように見えるため、使用を検討します。つまり、 again、「sensible」に見えます。しかし、ほとんどの場合、それは良い考えではありません。
「beta」は、Discourse のバージョン番号と Discourse のブランチ名の両方で使用される用語です。これが一部の人々を混乱させていることに気づきました。
「ベータ版」という言葉は、私のような半端なコンピューターリテラシーの持ち主には敬遠されるかもしれません。通常、「まだ機能を追加している」という意味ではなく、「品質のためにまだテスト中」という意味ですからね。
ブランチ名ではなく、バージョン名について考えているのだと思います。バージョン名から「ベータ」ブランチにいると勝手に思い込んでいました（実際には違いますが）。なので、今まで何も気になりませんでした…。
はい。tests-passed にいるのにバージョンが「beta」と表示され、すでにいる beta バージョンと同じ beta バージョンを取得するアップグレードができるのは、混乱を招く（または混乱を招く可能性がある）と思います。そして、beta リリース間には数週間と数百回のコミットがあります。
上記のディスカッションと参照資料の一部を組み込むために、このガイドにいくつかの編集を加えました。Configure a supported tracking branch to get Discourse software updates