Ich frage mich, ob wir Plugins eine Versionsnummer geben können, um Plugin-Listen mit der minimalen und maximalen Version von Discourse zu ermöglichen, mit der es kompatibel ist.
Damit wir nicht in die Situation geraten, dass unser Plugin aktualisiert wird, aber unsere Discourse-Version zurückliegt und dann die gesamte Website abstürzt.
Es gibt zwei breite Klassen von Plugins und TC’s:
Offizielle Plugins sind bereits kompatibel, und wenn sie nicht kompatibel sind, gibt es normalerweise einen angestellten Entwickler, der die Dinge innerhalb weniger Tage repariert.
Es ist für Maintainer bereits schwierig genug, die Kompatibilität aufrechtzuerhalten, geschweige denn zu verfolgen, ob sie es sind oder nicht.
Es gibt eigentlich nur zwei Versionen, die praktisch zu pflegen sind:
stabletests-passedSie können das Pinning-System (Pinning plugin and theme versions for older Discourse installs (.discourse-compatibility)) verwenden, um bereits für stable zu pinnen. Es wäre schön, dies irgendwie hervorzuheben, um explizite Kompatibilität anzuzeigen, aber es bedeutet nicht, dass das Plugin nicht kompatibel ist, wenn kein Pin vorhanden ist.
Die Kompatibilität mit der neuesten Version könnte durch einen grünen Haken von CI auf GitHub angezeigt werden.
Das hängt von zwei Dingen ab:
Letzteres ist eine große Bitte an Drittanbieter-Maintainer, die Dinge kostenlos tun.
Für inoffizielle Plugins läuft Ihre Funktionsanfrage auf eine angemessene Finanzierung von Drittanbieter-Plugins hinaus.
Als erfahrener Plugin-Autor, der schon viel erlebt hat, kann ich Ihnen sagen, dass es fast unmöglich ist, Drittanbieter-Plugins zu finanzieren.
Der einzige Grund, warum meine Plugins noch funktionieren, ist:
Das ist wertvoll für mich, hat aber seine Grenzen.
Ich würde sagen, dass die Entwicklung von Drittanbieter-Plugins im Discourse-Ökosystem fast 
ist, wobei nur eine sehr kleine Handvoll Entwickler in der Lage ist, die Dinge angesichts der sehr anspruchsvollen Geschwindigkeit des Kerns am Laufen zu halten.
Andere Ausnahmen:
Da Sie sich wirklich nur auf die Kompatibilität von offiziellen Plugins verlassen können (und vielleicht auf eine Handvoll zusätzlicher von sehr aktiven Entwicklern wie mir oder Communiteq), schlage ich vor, dass Sie sich einfach darauf konzentrieren, die official Plugins zu verwenden, und für diese ist Ihre Funktionsanfrage meiner Meinung nach überflüssig, da ein Prozess vorhanden ist, um diese Dinge im Kern zu verfolgen.
Ich bin mir nicht sicher, wie ich eine maximale kompatible Version für ein Plugin definieren könnte. Ein einfaches Plugin könnte wahrscheinlich sagen, dass es bis mindestens 4.0 funktioniert, und wenn 4.0 kommt, könnte es immer noch funktionieren, weil CDCK keine abwärtskompatiblen Änderungen eingeführt hat.
Aber vielleicht hat das einfache Plugin etwas verwendet, das CDCK in 3.8 als veraltet markiert und in 3.10 entfernt hat… Ziemlich schwierig, dies zu berücksichtigen.
Weil du es nicht kannst.
Es wird veraltet sein, sobald der nächste Commit veröffentlicht wird.
Aber es ist einfach:
Überprüfen Sie dann auf das grüne Häkchen, bevor Sie installieren.
Ich habe damit herumgespielt und eine Lösung in Github gefunden.
Ein einfaches grünes Häkchen für den letzten CI-Job reicht also nicht aus, da sich Dinge kürzlich geändert haben könnten, die das Plugin brechen könnten. Grundsätzlich müssen Sie die CI-Jobs erneut ausführen, wenn Discourse Branches aktualisiert.
In diesem Beispiel-Repository habe ich eine effiziente Lösung ausgearbeitet. Es handelt sich im Grunde um einen geplanten Workflow, der die wichtigen Branches des Discourse-Repositorys überprüft, um zu sehen, ob es Änderungen gibt. Wenn es welche gibt, löst er den normalen CI-Workflow aus, der die Testsuite ausführen sollte. In Ihrer Readme können Sie dann einige Badges platzieren, um zu zeigen, wie CI-Workflows gegen die neuesten Änderungen ausgeführt wurden.
Der Überwachungs-Workflow läuft in Sekunden. Wenn er geplant ist, verbraucht er nur 1 Minute GitHub-Action-Zeit.
Offensichtlich hängt die Zuverlässigkeit des gesamten Setups von der Anstrengung des Plugin-/Theme-Component-Entwicklers ab, eine gute Testsuite zu erstellen.
Und Sie haben immer noch das UX-Problem, dass Sie auf der “Update”-Seite von Discourse nicht wissen, ob der letzte CI-Job für eine bestimmte Version fehlgeschlagen ist.
Neben einem Überwachungs-Workflow, der ein Plugin neu erstellt, wenn sich der Discourse-Branch ändert, müssen Sie ein Build-Artefakt erstellen, das das Ergebnis (Pass/Fail) aufzeichnet. In Ihren Plugin-Metadaten sollten Sie auf dieses Artefakt verweisen können, und Discourse sollte dieses Artefakt abrufen, um die Kompatibilität/das Ergebnis in der Update-Oberfläche anzuzeigen.
Es ist keine narrensichere Konstruktion, aber es ist etwas.
Deshalb habe ich „bei jedem neuen Commit von Core in CI“ geschrieben 
Wir hatten eine Weile ein Dashboard auf Pavilion, das genau all dies tat.