プラグインと 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 プラグインの使用に焦点を当てることをお勧めします。それらのプラグインについては、コアとの互換性を追跡するプロセスが既に存在するため、あなたの機能リクエストは冗長であると考えています。