Plugin- und Theme-Versionen für ältere Discourse-Installationen anheften (.discourse-compatibility)

[Discourse]

Hintergrund

Manchmal müssen Themes/Plugins Änderungen vornehmen, die nur mit der neuesten Version von Discourse kompatibel sind. In diesem Fall können ältere Versionen von Discourse angewiesen werden, eine ältere „gepinte“ Version des Plugins zu verwenden.

Dies wird durch eine .discourse-compatibility-Datei im Stammverzeichnis eines Theme-/Plugin-Repositorys erreicht. Es handelt sich um eine YAML-Datei, bei der die Schlüssel die Discourse-Core-Version angeben und die Werte der entsprechenden Version Ihres Themes/Plugins entsprechen.

Discourse-Core-Versionen können mit den Operatoren < und <= angegeben werden. <= ist aus historischen Gründen der Standard, aber im Allgemeinen ist es sinnvoller, < zu verwenden.

Pinning einer Theme-/Plugin-Version

Wenn beispielsweise eine Änderung in der Discourse-Core während 3.2.0.beta2-dev (in version.rb zu finden) vorgenommen wird und Ihr Plugin/Theme davon abhängig wird, würden Sie einen Eintrag in der .discourse-compatibility-Datei wie folgt hinzufügen:

< 3.2.0.beta2-dev: abcde

wobei abcde ein Verweis auf den „Legacy“-Commit-Hash IHRES PLUGINS ist, der für ältere Versionen von Discourse verwendet werden sollte.

Jeder, der eine ältere Version von Discourse verwendet (z. B. 3.2.0.beta1 oder 3.1.4), verwendet die Version abcde Ihres Themes/Plugins. Jeder, der 3.2.0.beta2-dev oder neuer verwendet, verwendet weiterhin die neueste Version.

Mehrere Einträge

Im Laufe der Zeit können Sie der .discourse-compatibility-Datei mehrere Zeilen hinzufügen. Discourse wählt immer die „niedrigste“ Spezifikation, die mit der aktuellen Discourse-Core-Version übereinstimmt. Die Reihenfolge der Zeilen in der Datei spielt technisch gesehen keine Rolle, aber wir empfehlen, die neuesten Einträge oben zu platzieren.

Änderungen für alte Discourse-Versionen „zurückportieren“

Stellen wir uns eine .discourse-compatibility-Datei wie diese vor, mit zwei verschiedenen Versionsspezifikationen, die an bestimmte Plugin-Commits angeheftet sind:

< 3.2.0.beta1-dev: commithashfordiscourse31
< 3.1.0.beta1-dev: commithashfordiscourse30

Wenn Sie eine Änderung für Discourse 3.1 „zurückportieren“ müssen, würden Sie wie folgt vorgehen:

1. Erstellen Sie einen Branch vom alten Commit (git checkout -b mein_branch_name commithashfordiscourse31)

2. Committen Sie Ihre Änderung und pushen Sie sie an das Origin. Wenn Sie die Branch-Schutzfunktionen von GitHub verwenden, möchten Sie diesen Branch möglicherweise vor versehentlichem Löschen schützen

3. Aktualisieren Sie die .discourse-compatibility-Datei im Haupt-Branch, sodass sie nun auf Ihren neuen Commit im 3.1-Support-Branch verweist

Praxisbeispiel

Hier ist eine tatsächliche .discourse-compatibility-Datei aus dem discourse-solved Plugin. Beachten Sie, dass diese zum Zeitpunkt der Erstellung immer noch die „Legacy“-Syntax ohne explizite Operatoren < oder <= verwendet. Daher wird jede Zeile automatisch als <= interpretiert.

.discourse-compatibility

---

Dieses Dokument wird versioniert – schlagen Sie Änderungen auf github vor.

[NateDhaliwal]

Wenn die Version < 3.5.0.beta8-dev ist, würde sie 3.5.0 enthalten?

[david (David Taylor)]

Nr. 3.5.0 gilt als „höher“ als die Vorabversion „3.5.0.beta8-dev“.

Sie können Vergleiche jederzeit in einer Ruby-Konsole ausprobieren:

> Gem::Version.new("3.5.0") < Gem::Version.new("3.5.0.beta8-dev")
=> false

[NateDhaliwal]

Verstanden. Danke für die Erklärung!