Plugin- und Theme-Versionen für ältere Discourse-Installationen fixieren (d-compat-Branches)

Dokumentation Entwicklerhandbücher
1

:open_book: Hintergrund

Theme- und Plugin-Entwickler möchten in der Regel die neueste Version von Discourse ansprechen, ohne sich um Abwärtskompatibilität kümmern zu müssen. Doch Seiten, die ältere Discourse-Versionen betreiben, benötigen weiterhin eine Version des Themes/Plugins, die für sie funktioniert.

Um diese Lücke zu schließen, kann Discourse angewiesen werden, eine ältere „gepinnte

17 „Gefällt mir“
From Discourse 3.2: adding -dev suffix to beta versions under active development
Introducing .discourse-compatibility: pinned plugin/theme versions for older Discourse versions
Links not appearing since the last theme component update
Theme component update always installs old version (via rake or manually) (solved)
Mint Theme
Current Projects - May 2026
Trading Buttons
Upcoming post menu changes - How to prepare themes and plugins
Visiting /admin/upgrade may lead to a server error
Category Icons
What is the purpose of the compatibility entry in the theme skeleton?
Invalid version list in discourse themes
Give Plugin versions for minimum and maximum discourse version
4

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

5

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
5 „Gefällt mir“
6

Verstanden. Danke für die Erklärung!

1 „Gefällt mir“
7

Dieses Dokument wurde aktualisiert, um die neue d-compat/*-Strategie aus RFC: A new versioning strategy for Discourse zu beschreiben, die nun zur Verfügung steht.

5 „Gefällt mir“
8

Die Strategie d-compat/<YYYY>.<M> würde doch einen Branch für jede spezifische Version erfordern, oder? Es ist kein Bereich möglich, wie bei der Konstruktion .discourse-compatibility.

Wenn ich also ein Plugin pflege, das von ESR bis zur neuesten Version funktioniert: Wenn ich die Entwicklungen dann zur neuen ESR (die mit der alten ESR überlappt) verschiebe, müsste ich für jede Zwischenversion Branches erstellen?

Zum Beispiel: Derzeit ist ESR 2026.1, Release 2026.6 und die neueste Version 2026.7, wobei 2026.5 noch unterstützt wird. Wenn ich mein Plugin zur neuen ESR (2026.7) verschiebe, während die alte ESR von Discourse noch unterstützt wird, müsste ich die folgenden Branches erstellen:

  • d-compat/2026.1
  • d-compat/2026.2
  • d-compat/2026.3
  • d-compat/2026.4
  • d-compat/2026.5
  • d-compat/2026.6

Wobei .2 bis .5 (einschließlich) von Discourse als EOL (End of Life) gelten, aber Nutzer sie möglicherweise noch verwenden.

Oder findet Discourse den am besten passenden Branch, wenn einer fehlt, anstatt den Hauptbranch anzunehmen?

Zum Beispiel: Wenn ich Version 2026.5 betreiben würde und die einzigen Branches d-compat/2026.1 und d-compat/2026.6 wären, welcher Branch würde verwendet?

  1. d-compat/2026.1, da dies die nächstliegende kompatible Version ist?
  2. main, da es keinen spezifischen Branch gibt?
1 „Gefällt mir“
9

Ja, für jede Version des Discourse-Kerns ist ein eigener Branch erforderlich. Wir empfehlen, deren Erstellung zu automatisieren:

main würde verwendet.

2 „Gefällt mir“