Themes und Komponenten auf dem Standardkanal latest werden automatisch deaktiviert, und Theme-Autoren müssen auf unintuitive Workarounds zurückgreifen.
Ich bin hier darauf gestoßen: Featured Topics - #76 by cogdog Es ist ziemlich unintuitiv, dass alle Mindestversionen ein Format wie xxx.x.999 unterhalb der aktuellen Version verwenden müssen, die sie eigentlich abdecken sollen.
Plattform
Self-Hosted Discourse auf dem latest-Branch
Discourse-Version: 2026.8.0-latest.1
Betroffen: Erstellung von Themes/Theme-Komponenten (about.json-Metadaten) und Theme-Kompatibilitätsprüfungen
Beschreibung
Tatsächliches Ergebnis:
Ein Theme mit "minimum_discourse_version": "2026.8.0" in seiner about.json wird als inkompatibel eingestuft und automatisch deaktiviert, wenn die Site den -latest-Build 2026.8.0-latest.1 ausführt. Der einzige Weg, das Theme aktiv zu halten, besteht darin, eine niedrigere Version wie "minimum_discourse_version": "2026.7.999" zu setzen.
Ein ähnliches Problem tritt auf, wenn ein Theme importiert wird, das minimum_discourse_version auf einen -latest-Wert setzt (z. B. 2025.12.0-latest), da dieser als ungültig abgelehnt wird – siehe bestehenden Bericht: 主题配置文件中minimum_discourse_version不支持日期化版本格式
Erwartetes Ergebnis:
Da 2026.8.0-latest.1 ein -latest-Build der Release-Linie 2026.8.0 ist, sollte er eine Mindestanforderung von 2026.8.0 erfüllen. Latest-Builds sind neuer als die entsprechende veröffentlichte Version, nicht älter.
Aber eine -latest-Version ist eine Version vor dem Release dieser Version. Darauf basierten die Kompatibilitätseinträge seit Jahren.
Die Art und Weise, wie du das mit <2026.7.999 gelöst hast, wirkt zwar intuitiv, aber warum hast du nicht <2026.8.0-latest angegeben?
Wenn ich ein bestimmtes Commit brauche, das während der 2026.8-Entwicklung hinzugefügt wurde, kann ich sicher sein, dass jeder, der das 2026.8-Release nutzt, es hat. Aber ich kann nicht sicher sein, dass jeder, der 2026.8-latest nutzt, es hat. Vielleicht hat deren letztes Update stattgefunden, bevor das bestimmte Commit hinzugefügt wurde. Wenn 2026.8 also standardmäßig 2026.8-latest enthalten würde, könnte es zu Problemen kommen. Ich finde es besser, wenn der Administrator ein paar Wochen warten muss, bevor er ein Theme verwenden/aktualisieren kann, als das Risiko einzugehen, dass etwas kaputtgeht, weil das erforderliche Commit fehlte.
Das sollten wir beheben. Theme-Autoren sollten in der Lage sein, Folgendes zu tun:
minimumDiscourseVersion: "2026.8.0-latest"
Obwohl, wie @moin erwähnte, das riskant sein kann, da -latest sich auf eine ganze Reihe verschiedener Commits bezieht. In einer perfekten Welt sollten wir also auf das nächste Release warten, bevor wir in einem Theme/Plugin von einer neuen Kernfunktion abhängen.
Ich finde es ein bisschen schwer verständlich und muss auch in der Kompatibilitätsdatei diesen x.999-Ansatz verwenden. So sieht es aktuell in meiner Komponente aus:
2026.7.999: 93b5b22
2026.4.999: 0321b6d
Offensichtlich wurde eine Funktion in 2026.5.0 eingeführt, und um diese abzugleichen, muss ich 2026.4.999 eintragen?
Ich habe das in letzter Zeit nicht verwendet, aber die Beispiele des Discourse-Teams nutzten normalerweise nicht die vorherige Version mit .999, sondern die aktuelle Version mit dem Suffix -latest.
In der Vergangenheit ja, daher gibt es einige ältere Themes/Plugins, die das noch so machen (und ich vermute, dass Menschen/Roboter weiterhin das Legacy-Muster kopieren).
Heutzutage kannst du jedoch <- oder >-Indikatoren auf der linken Seite der Kompatibilitätsdatei verwenden. Du kannst also Folgendes tun:
<2026.7.0-latest: 93b5b22
Aber wir versuchen heutzutage auch, die Kompatibilitätsdatei für andere Zwecke zu vermeiden. Stattdessen verlassen wir uns auf die automatischen d-compat/*-Branches, um die Kompatibilität mit älteren Versionen sicherzustellen.
Dokumentationen zu beiden Mustern (alt und neu) findest du hier: