プラグインにバージョン番号を付与し、プラグインが互換性のあるDiscourseの最小バージョンと最大バージョンをリストできるようにできないかと考えています。
これにより、プラグインが更新されたものの、Discourseのバージョンが遅れていて、サイト全体が壊れてしまうような事態を回避できます。
プラグインと TC には、大きく分けて 2 種類あります。
- 公式
- サードパーティ
公式プラグインは既に互換性が維持されており、互換性がない場合でも、通常は給与を得ている開発者が数日以内に修正します。
サードパーティ製プラグイン
メンテナーが互換性を維持することは既に十分困難であり、ましてや互換性があるかどうかを把握することさえ困難です。
維持する上で現実的なバージョンは、実質的に 2 つしかありません。
- 最新の
stable - 最新の
tests-passed
ピン留めシステム (Pinning plugin and theme versions for older Discourse installs (.discourse-compatibility)) を使用すると、既に stable 用にピン留めできます。それを何らかの方法で表示して明示的な互換性を示すのは非常に良いことですが、ピン留めがないからといって、そのプラグインが互換性がないわけではありません。
最新バージョンとの互換性は、GitHub の CI による緑色のチェックマークで表示できるかもしれません。
それは 2 つのことに依存します。
- 包括的な CI セットアップ (理想的には Discourse プラグイン標準に基づく)
- 非常に高いテストカバレッジ
後者は、無償で活動しているサードパーティのメンテナーにとっては大きな要求です。
非公式プラグインの場合、あなたの機能リクエストは、サードパーティ製プラグインの適切な資金調達に集約されます。
経験豊富なプラグイン作成者として、サードパーティ製プラグインの資金調達はほぼ不可能だと断言できます。
私のプラグインが機能し続けている唯一の理由は次のとおりです。
- 私自身がそれらを使用している
- エコシステム内での評判を維持する手段として
これは私にとって価値がありますが、限界があります。
Discourse エコシステムにおいて、サードパーティ製プラグインの開発は、コアの非常に要求の厳しい速度に対応し続けることができる開発者はごく少数であり、ほぼ 
に近い状態だと思います。
その他の例外:
- Communiteq のような主要なホストが使用しているプラグイン - 彼らには意見があるかもしれませんが、彼らでさえほとんどのクライアントが望むものに集中する必要があり、リソースにも限界があります。
- カスタムウィザードとイベントプラグインにはサブスクリプションシステムが付属しています - ここでも Angus からその方向性について意見を聞くことができます。
まとめ
公式プラグイン (そしておそらく私や Communiteq のような非常に活発な開発者からの少数の追加プラグイン) の互換性しか本当に頼れないことを考えると、official プラグインの使用に焦点を当てることをお勧めします。それらのプラグインについては、コアとの互換性を追跡するプロセスが既に存在するため、あなたの機能リクエストは冗長であると考えています。
「いいね！」 7
プラグインの最大互換バージョンをどのように定義できるか分かりません。単純なプラグインは、少なくとも4.0まで動作すると言えるかもしれませんが、CDCKが破壊的な変更を導入しなかった場合、4.0が登場してもまだ動作する可能性があります。
しかし、単純なプラグインがCDCKが3.8で非推奨にし、3.10で削除した何かを使用した可能性もあります… これを考慮に入れるのはかなり難しいです。
できないからです。
次のコミットがリリースされるとすぐに古くなります。
しかし、それは簡単です。
- CIでコアの新しいコミットごとに実行される（バックエンドとシステム最小値）網羅的な（95％カバレッジ）プラグインテスト
インストールする前に緑色のチェックマークを確認してください。
これを試してみて、GitHubで解決策を見つけました。
したがって、最新のCIジョブの緑色のチェックマークだけでは不十分です。最近変更された可能性があり、プラグインを破損させる可能性があるためです。基本的に、Discourseがブランチを更新したときにCIジョブを再実行する必要があります。
この例のリポジトリで効率的な解決策を考え出しました。これは基本的に、Discourseリポジトリの重要なブランチをチェックして変更がないか確認するスケジュールされたワークフローであり、変更があった場合は通常のCIワークフローをトリガーしてテストスイートを実行します。READMEにバッジを配置して、最新の変更に対してCIワークフローがどのように実行されたかを示すことができます。
監視ワークフローは数秒で実行されます。そのため、スケジュールされている場合、GitHubアクションの時間は1分しか消費しません。
明らかに、このセットアップ全体の信頼性は、優れたテストスイートを作成するためのプラグイン/テーマコンポーネント開発者の努力にかかっています。
そして、Discourseの「更新」ページから、特定のバージョンの最新のCIジョブが失敗したかどうかわからないというUXの問題がまだあります。
したがって、Discourseブランチが変更されたときにプラグインを再構築する監視ワークフローを持つことに加えて、結果（合格/不合格）を記録するビルド成果物を作成する必要があります。プラグインメタデータでこの成果物を指すことができ、Discourseはこの成果物を取得して、更新インターフェイスに互換性/結果を表示できるはずです。
それは万能な構造ではありませんが、何かしらです。
だからこそ、「CIでのコアの新しいコミットごとに」と書いたのです 
しばらくの間、Pavilionにこれらすべてを正確に行うダッシュボードがありました。