Discourse は LTS リリースを出荷しません

一般
1

discourse-compatability については知らなかったので、調べてみる必要があります。

これを指摘したいと思います。なぜなら、Discourse チームが stable をどのように考えているかと、他の Discourse コミュニティやフォーラム管理者のコミュニティが Discourse の stable オファリングをどのように考えているかとの間に、大きな隔たりがあるように思われるからです。

stable が LTS の定義を満たさない主な理由

1) stable は、話題に上がるとスタッフから積極的に推奨されない

個々の投稿者を特定したいわけではありませんが、テーマを示すためにスタッフの投稿をいくつか紹介します。

tests-passed はある意味で stable よりも安定しています。なぜなら、discourse.org が実行しているものであり、最もテストされているからです。

そのため、Discourse は永続的なベータ状態にあり、常に新機能の開発と改善に取り組んでいます。この場合、ベータは不安定を意味するものではありません。私たちは、millions の月間ページビューを持つサイトを、tests-passed およびベータ版でホストしています。

stable チャネルは、tests-passed よりも必ずしも「安定」しているわけではありません。既知のバグがあるという考え方であり、特定の機能セットと改善のチェックポイントとして機能します。tests-passed では、新しいバグが導入され、数コミット後に修正される可能性があります。

Discourse は「永続的なベータ版」であるというメッセージは、本番環境 / 開発者以外のユーザーが望む体験とは異なります。

簡単な DuckDuckGo 検索で、Discourse stable の上位 10 件のリンクのいずれも、stable の使用を 支持 しているようには見えません。実際の品質に関係なく、スタッフが普遍的に stable の使用を避けるように導いている場合、それは目的適合性に対する否定的な印象を与えます。

stable は素晴らしいかもしれませんが、使用しない方が良いと繰り返し言われれば、真剣な導入を検討することはありません。

2. LTS はセキュリティバグ修正以外にもバグ修正を受け取る

LTS は機能アップグレードを受け取らないものですが、バグ修正は受け取ります。スタッフ自身のコメントによると、Discourse ではセキュリティ以外の問題に対するバグ修正のバックポートに労力がかけられていないようです。これは真実ではないかもしれませんが、私たちはそのように言われています。

3. LTS は簡単なインストール手順を備えている

インストールガイド には、stable の 存在 さえ言及されていません。

4. LTS は広く使用されている

あなたの投稿の前は、stable ブランチの広範な使用について聞いたことがありませんでした。実際に広く使用されていますか？隠されていることを考えると、疑わしいですが、それを言うための指標はありません。これは、人々が stable を本番環境の導入に使用する自信を与える重要な要素です。

5. LTS は明確なリリースサイクルとアップグレードノートを備えている

stable が明確に文書化されている中心的な場所が見当たりません。（見落としているだけかもしれませんが！）

LTS に期待することは、次のようなページです。

  • 現在アクティブなリリースバージョン
  • リリースノート（以下を含む）：
    • LTS バージョン間の主要な変更/機能
    • 前の LTS リリースからの移行手順（特に注意すべき破壊的変更）
    • 各バージョンの計画されたアクティブサポート期間

例：MediaWiki 、実際には主要なオープンソース LTS は同様のページを持っています。

このドキュメントは、ダウンタイムや手動介入が必要な破壊的変更がある場合に、計画を立てるのに役立ちます。

6. LTS は 1 つのリリースサイクル内で重大な破壊的変更がない

これは stable の場合かもしれませんが、アップグレードボタンを押すとフォーラムがダウンするという経験に慣れすぎていて、確信が持てません。ここで求めているのは、何かを壊すバージョン間の移行時に、より明確な警告だと思います。

7. LTS は少なくとも 1 つの完全な LTS リリースサイクルで API 廃止警告を提供する

これらは、月単位ではなく、年単位で測定されるべきです。

8. LTS はスロット化されている / サポート期間が重複している

大規模な LTS は、2 つの LTS バージョン間でサポート期間が重複します。stable は単に次のバージョンにバイナリフリップするだけのようです。（中心的なドキュメントページがないため、私の印象も誤っている可能性があります）

9. 非 LTS から LTS へのアップグレードは簡単である

後方互換性をサポートする必要はありませんが、LTS が利用可能な場合、ブランチを LTS にクリーンに切り替える方法が明確ではありません。フォーラムにはそれに関する投稿があるようですが、ここでも中心的なドキュメントは見つかりませんでした。

私は Discourse のファンですが、これは私自身が遭遇する一般的な問題であり、他の多くの人も同様です。現在の stable は LTS ではなく、単なるブランチです。

「いいね！」 4
2

プラグインのバンドルとは無関係のようですので、別のトピックに移動しました。

「いいね！」 3
3

管理ダッシュボードの悲しい顔と、「ディスコースの更新」で多くのコミットが遅れていることを比較した場合、
クリティカルな更新は tests-passed の一部であり、「すべて更新」をハッピーフェイスから悲しいフェイスにすぐに更新すると、tests-passed と同期します。

4

この特定のアップデートは、コンソールから再構築する必要があると思います。2回。

「いいね！」 1
5

Discourse は変更の速度が速く、野心的なロードマップを持っているようです。

それをサポートするには、多くのユーザーからのフィードバックが必要です。tests-passed を促進する明確な暗黙の戦略があると考えています。それは新しい変更に対する早期フィードバックをサポートするためです。

その見返りに、ユーザーは無料のソフトウェアと新機能を得ます。それは一種の協定です。この取引は、時間が経つにつれて成功したことが証明されていると思います。

安定版ビルドは開発にあまり役立たないため、それほど促進することはビジネス上の利益にならないかもしれません（これは私の個人的な意見であり、CDCK を代表するものではありません）。

安定版に関するもう 1 つの問題は、さらに重要なことですが、次のとおりです。

通常、安定版バージョン間には多くの変更があり、重要な非推奨や API の変更も含まれます。開発者、サイト管理者、またはテーマ作成者として tests-passed に関与することで、次の安定版マイルストーンに到達するたびに大きな山を登るのではなく、変更に小さな断片で対処する機会が得られます。

これらの大きなジャンプをサポートするには、ステージングサイトと、実行するテストケースのセットが必要になるでしょう。

自分でカスタマイズを行っていない場合は、安定版を選択するかもしれませんが、アドオンが次のアップグレードに対して十分にメンテナンスされていることを確認するために、影響力の弱い他のユーザーに大きく依存することになります。アップグレード時に一部の要素がサポートを失い、その時点で困った状況に陥る可能性があります。また、開発者が安定版をまったくサポートしておらず、安定版ビルドをサポートするためにプラグインの「カット」をフォークして準備する必要がある場合もあります。（ただし、優れたピン留めシステムが用意されているため、それほど多くの作業ではありません）

Discourse におけるもう 1 つの重要な点は、ユニットテストが非常に集中的であるため、test-passed ブランチは通常、安定性の観点から非常に良好であるということです。

「いいね！」 4
6

プラグインのバンドルといった不評な変更を取り消すことを経営陣が拒否していることを考えると、この部分は正確ではないと思います。おそらく QA の観点からはそうかもしれませんが、それでも過去にいくつかの厄介なバグが修正されなかったことがあります。結局のところ、彼らがお金と時間を投資している当事者であり、彼らが決定を下すことができることは理解していますが、私の意見では、それはより多くのフィードバックを得るための戦略ではないと思います。

適切な LTS をサポートしないより現実的な理由は、チームの誰かがそれを管理/文書化するのに時間を費やすことになるからだと思います。主にセルフホスティングユーザーに利益をもたらす機能なので、彼らにとっては時間の浪費と見なされると想像します。しかし、それは期待される機能であり、それがないことは、フォーラム管理者がフォーラムソフトウェアを選択する際に、他の同等のソフトウェアがより安定した製品を提供しているため、実際の欠点となります。

7

それどころか、プラグインのバンドルはまさにそれらの使用を促進し、その結果、より多くのフィードバックを得るためのものだと私は考えています。

8

マネジメントは、別のスレッドで開発チームの生産性に影響を与えているバージョン不一致の問題を具体的に指摘しました。それはもっともな理由ですが、別のスレッドで議論されたように、根本的な問題を解決するための理想的な方法ではありません。