RFC: Eine neue Versionierungsstrategie für Discourse

Entwickler
22

Ok, aber ich glaube, dann verstehe ich das Problem noch weniger :confused:

Letztendlich spielt es laut @davids neuesten Kommentaren keine Rolle, also nur um es zusammenzufassen.

Das vorgeschlagene Modell ist eine monatliche Veröffentlichung plus 2 ESR-Versionen, also z. B. für 2026:

  • 2026.1
  • 2026.2
  • 2026.3
  • …
  • 2026.8
  • 2026.9
  • 2026.10
  • …

Wenn wir also im Oktober 2026 sind und .2 und .8 ESR-Versionen sind, bedeutet das 4 unterstützte Versionen.

Und mein Gedanke war: Wäre es nicht einfacher, im Grunde vierteljährliche Versionen zu haben, also für 2026:

  • 2026.1
  • 2026.2
  • 2026.3
  • …

Und nur die aktuelle und die vorherige Version würden weiterhin unterstützt, also im Oktober 2026 wären es 2.

Und die ganze Überlegung war, dass dies vielleicht sowohl für Entwickler als auch für Benutzer einfacher wäre. Aber wie oben erwähnt: @david hat klargestellt, dass weniger häufige Veröffentlichungen keine Option sind.

2 „Gefällt mir“
23

Verstanden. Das ist ungefähr so, wie ich es erwartet habe. Tatsächlich wäre in diesem Fall zumindest mittelfristig etwas Tool-Unterstützung wünschenswert.

So stelle ich es mir vor: Sie befinden sich auf einem bestimmten Release-Kanal (latest, release, esr) und wechseln normalerweise relativ schnell zur nächsten Version. Daher wäre es praktisch, eine Nachricht und/oder Benachrichtigung zu erhalten, wenn die neue Version verfügbar ist, und einen einzigen Befehl zum Wechseln zu haben. Und für Fälle, in denen Sie die Einführung einer neuen Version verzögert haben, wäre es auch schön, daran erinnert zu werden, wenn die aktuell verwendete Version veraltet/nicht mehr unterstützt wird. Bonuspunkte, wenn das jeweilige Tool auch einen schnellen Wechsel der Release-Kanäle ermöglicht :slightly_smiling_face:
Aber ich verstehe, wenn das im Moment keine Priorität hat und Sie immer noch empfehlen, auf test-passed/latest zu bleiben.

Ich verstehe. Im Kontext meiner Arbeit gilt die Bereitstellung einer Funktion für Kunden als „schnell“ :sweat_smile:
Auch, wie oben erwähnt, war mein Gedanke, dass ein Wechsel zu einem vierteljährlichen Zeitplan Ihr Leben (und das Leben von Plugin-/Theme-Entwicklern) tatsächlich einfacher machen würde, da weniger Branches gewartet werden müssen. Wenn das also nicht der Fall ist, dann ergibt das für Sie wohl wirklich keinen Sinn :slightly_smiling_face:

6 „Gefällt mir“
24

Ich sehe keinen Vorteil in diesem von Ihnen vorgeschlagenen jahresbasierten Versionsschema. Bleiben Sie bei den SemVer-konformen Versionsnummern!

25

SemVer selbst ist nicht wirklich für große Anwendungen konzipiert. Ich verstehe es so, dass es viel stärker auf Bibliotheken abzielt, die von Software genutzt werden, und insbesondere die Logik der Versionsnummerierung ist um die API des Pakets herum aufgebaut.

Wir könnten Semver jedoch auf unsere API(s) anwenden. Stärkere Garantien für die APIs, die Discourse bereitstellt, sind sicherlich eine lohnenswerte Diskussion, aber ich denke, sie ist von dieser hier getrennt.

Nun verstehe ich, dass Sie nicht gesagt haben, wir sollten SemVer-konform sein – Sie sagten nur, wir sollten Zahlen verwenden, die mit dem von SemVer spezifizierten Nummerierungssystem konform sind.

  1. Eine normale Versionsnummer MUSS die Form X.Y.Z haben, wobei X, Y und Z nicht-negative ganze Zahlen sind und KEINE führenden Nullen enthalten dürfen. X ist die Hauptversion, Y ist die Nebenversion und Z ist die Patch-Version. Jedes Element MUSS numerisch erhöht werden. Zum Beispiel: 1.9.0 → 1.10.0 → 1.11.0.

Ich denke, der Hinweis auf „führende Nullen“ ist das Einzige, was wir brechen würden, wenn wir diesen Weg einschlagen.

Ansonsten denke ich, dass jede SemVer-Bibliothek die von uns vorgeschlagenen Versionsnummern immer noch parsen und richtig sortieren könnte.

Davon abgesehen, können Sie mehr darüber erzählen, warum Sie denken, dass die Einhaltung eines SemVer-Nummerierungssystems einen Wert hat?

2 „Gefällt mir“
26

Der OP sagt, dass Sie keine führenden Nullen verwenden, wenn ich das richtig verstehe.

Ich denke, es wurde auch ein überzeugender Grund für die Verwendung von führenden Nullen (Sortierung nach Versionen) vorgeschlagen. Sind führende Nullen der aktuelle Plan? (Ich mag immer noch Monatsversionen statt Serienversionen).

3 „Gefällt mir“
27

Der Sinn von SemVer ist, dass die Versionsnummer nützliche Informationen kommunizieren sollte. Die einzige Information, die Ihr vorgeschlagenes Schema kommuniziert, ist die Erdumrundung der Sonne. Diese Information ist für den Verbraucher der Software nicht sehr nützlich.

Wenn ich aus irgendeinem Grund das Veröffentlichungsdatum wissen wollte, würde ich mir die Veröffentlichung ansehen und das vollständige Datum erhalten.

Nicht wirklich. Der Punkt ist, die Art der Veröffentlichung dem Benutzer mitzuteilen.

Wenn die Veröffentlichung eine Patch-Version ist, bedeutet dies, dass die Änderung nichts enthält, von dem erwartet wird, dass es den Arbeitsablauf der Benutzer der Software beeinträchtigt.

Wenn die Veröffentlichung eine Minor-Version ist, bedeutet dies, dass die Änderung die Hinzufügung neuer benutzeroberflächenbezogener Komponenten enthält, aber nichts, was die bestehenden Arbeitsabläufe der Benutzer der Software beeinträchtigen würde.

Wenn die Veröffentlichung eine Major-Version ist, bedeutet dies, dass die Änderung Änderungen enthält, die bestehende Arbeitsabläufe der Benutzer der Software beeinträchtigen können.

Die Bestimmung, welche der Versionskomponenten erhöht werden sollte, ist bei einer Software mit einer einzigen Benutzeroberfläche eindeutiger, aber die Prinzipien bleiben auch bei einer Software wie Discourse, die eine Vielzahl von Schnittstellen und Verbrauchertypen (z. B. Plugin-Entwickler, API-Konsumenten, Forenmitarbeiter, Endbenutzer) aufweist, gleich.

Selbst wenn die Wahl der zu erhöhenden Komponente bei diesem Softwareprojekt etwas subjektiver ist, hat die Versionsnummer immer noch eine Bedeutung, anstatt nur eine beliebige Zahl zu sein, wie es bei Ihrem Vorschlag der Fall ist.

2 „Gefällt mir“
28

Das habe ich ein paar Beiträge weiter oben vorgeschlagen.

Im Gegensatz zu Semver macht das vorgeschlagene Versionsnummerierungsschema sofort klar, ob eine Version noch unterstützt wird (wie Ubuntu). Da dies auch von der Erdumlaufbahn um die Sonne abhängt, ist dies tatsächlich sinnvoll.

Dies richtet sich eindeutig an Pakete und Bibliotheken. Jede Discourse-Veröffentlichung enthält Änderungen, die bestehende Arbeitsabläufe der Benutzer der Software unterbrechen können. Ich habe sogar Sicherheitspatches gesehen, die das tun. Semver ist für komplexe Anwendungen nicht nutzbar.

Doch, wirklich, siehe

Sobald Sie Ihre öffentliche API identifiziert haben, kommunizieren Sie Änderungen daran mit spezifischen Inkrementen Ihrer Versionsnummer.

5 „Gefällt mir“
29

Nur um einen Punkt hervorzuheben, der vielleicht untergeht: Ich denke, Discourse leistet hier hervorragende Arbeit. Eine Verbesserung wäre, zumindest die Themen hervorzuheben, zu denen Sie bereits etwas geschrieben haben, das Änderungen und mögliche Bruchstellen innerhalb dieses Upgrade-Zyklus beschreibt. Zum Beispiel musste ich bei der Veröffentlichung 3.5 die Versionshinweise öffnen, zum Blog durchklicken und dann zufällig auf den Link zum Bündeln von Plugins mit Discourse-Kern klicken, um das Detail zu erfassen, dass das Belassen dieser Plugins in meiner Konfigurationsdatei Upgrades beeinträchtigen könnte.

Es wäre großartig, solche Hinweise auf einer Seite/einem Thema für ESR-Veröffentlichungen hervorzuheben, selbst wenn es sich nur um eine Reihe von Links zu vorhandenen Themen handelt, die vor der Durchführung eines ESR-Upgrades überprüft werden sollten.

Dies liegt jedoch möglicherweise außerhalb des Rahmens dieses Threads – mein Feedback zur Versionsänderung ist, dass ich sie begrüße und die Transparenz hier schätze. Ich denke, dies wäre eine großartige Verbesserung, die die Dinge vereinfachen und uns mehr Optionen für das Self-Hosting geben würde.

Vielen Dank!

4 „Gefällt mir“
30

Ja, und es ist eine so gute Idee, dass ich denke, der Ersteller des Beitrags sollte das widerspiegeln!

3 „Gefällt mir“
31

Die führenden Nullen und ob die Synchronisierung mit Monaten expliziter angestrebt werden soll, wird derzeit geprüft. @david wird ein Update teilen, sobald die Gruppe, die daran arbeitet, eine Entscheidung getroffen hat.

7 „Gefällt mir“
32

Das sind nicht die wichtigen Informationen für einen Foren-Maintainer, der eine neue Version bewertet.

Nein, wirklich. Sie verpassen den eigentlichen Sinn von SemVer, indem Sie sich weigern zu verstehen, dass „API“ eigentlich nur die Schnittstelle bedeutet. Es gibt absolut keinen Grund, warum der Geist von SemVer nicht bei der Versionierung jeder Art von Software verwendet werden kann.

33

Ich denke, wir werden uns bei diesem Punkt nicht einig sein können, @per1234.

Hier ist eine verwandte Diskussion im GitHub-Repository für semver mit einer Antwort von einem der Maintainer:

Semver ist für „Endbenutzeranwendungen“ nicht wirklich nützlich, sondern eher für Bibliotheken, die Leute als Abhängigkeiten für ihre Projekte verwenden.

4 „Gefällt mir“
34

Es spielt keine Rolle, ob es sich um eine Bibliothek oder eine größere Anwendung handelt. Ein semantisches Versionierungsschema funktioniert auch für große Anwendungen perfekt. Es kann sogar für eine Sammlung von Anwendungen verwendet werden, die zu einer Plattform gebündelt sind, aber hier wird es ziemlich schwierig.

Die Hauptfrage ist, ob Sie den Weg der unterstützten Deprecation in einer Version gehen und diese erst in der nächsten Hauptversion entfernen. Funktionalität, die als veraltet markiert, aber weiterhin unterstützt wird, kann erheblichen Aufwand bedeuten. Wenn Sie Änderungen an Ihrem persistenten Datenmodell vornehmen, kann die Deprecation oft unmöglich werden. Wenn das passiert, können Sie nicht einmal eine Nebenversion mit veralteter Funktionalität durchführen und springen sofort zur nächsten Hauptversion. Hier haben große Anwendungen normalerweise Probleme. Sie gehen von 3.0.0 zu 3.0.1 zu 4.0.0, weil Sie keine Abwärtskompatibilität gewährleisten können. Wenn Sie häufig brüchige Änderungen haben, bietet Semver wenig Mehrwert.

Davon abgesehen. Ich bevorzuge diese Konstruktion, da sie Entwicklern klarer kommuniziert, dass es brüchige Änderungen geben wird. Das YYYY.N-Schema sagt mir als Entwickler nichts und als Administrator auch nichts.

Die Frage ist also, was möchten Sie mit der Version kommunizieren? Wenn Sie 6 Feature-Releases durchführen möchten (die brüchig sein können oder nicht), und jede 6. Version länger unterstützt wird mit Patches; und Sie möchten Patch-Releases nicht versionieren. Dann ist X.Y ein geeignetes Schema, bei dem Y=0 die länger unterstützte ist. X wäre einfach eine Zahl. Das Problem ist, wenn X das Jahr ist, wird Y schnell mit einem Monat assoziiert. Neuere, länger unterstützte Releases werden also im Januar veröffentlicht? Ich muss immer nachschauen, welche Ubuntu-Version eine LTS ist, was mich ärgert.

Was wäre also, wenn Discourse einfach mit der aktuellen Hauptversion weitermacht? Die nächste länger unterstützte Version heißt 4.0; und dann erhalten wir 4.1 bis 4.5 als Feature-Releases; gefolgt von 5.0, der neuesten länger unterstützten Version.

Dann haben Sie auch nicht diesen unangenehmen Moment, in dem eine Veröffentlichung aufgrund eines größeren Problems verzögert wird.

Sie könnten optional eine “Patch”-Nummer hinzufügen, wenn Sie explizit Patches veröffentlichen möchten (anstatt rollierende Patch-Releases zu haben). “Aber dann haben Sie x.y.z, was Semver ist”. Nun, nein, es sieht aus wie Semver, ist es aber nicht. Jede neue “Neben”-Version kann brüchig sein. Daher schlage ich vor, sich einfach an das X.Y-Versionsschema zu halten, wobei Y=0 → LTS ist.

Abgesehen von der Versionszeichenfolge. Ich mag den neuen Release-Plan.

4 „Gefällt mir“
35

Ja, hier sind die Dinge heute effektiv, besonders mit dem flexiblen Theme-System.

Daher denke ich, dass Sie hier genau richtig liegen:

Das bedeutet auch, dass der „Major“-Teil unserer aktuellen Versionsnummer sehr wenig kommuniziert.

Daher schien es, als ob „Hey, wir könnten genauso gut ein Jahr dort verwenden, um etwas zu kommunizieren.“

:rocket:

4 „Gefällt mir“
36

Diese Diskussion sieht nicht gut aus. Ich sehe eine Entscheidung des Entwicklungsteams, ein neues Versionierungssystem zu übernehmen, das für sie sinnvoll ist, und andere, die plötzlich der Meinung zu sein scheinen, dass die Discourse-Version semantische Versionierung befolgt hat … was sie nicht tat. Es war schon immer ein Rolling Release, zumindest seit 1.0, oder?

Aber die Argumente auf allen Seiten der Debatte scheinen fehlerhaft zu sein:

  • “Industriestandard”: Linux verwendet gerade Majors für stabile und ungerade Majors für die Entwicklung.
  • “Erde dreht sich um die Sonne”: Nun, wenn Sie zum Islam konvertieren, geraten Sie in Schwierigkeiten, weil Sie Versionen fallen lassen und nein, es wird nicht mehr mit der Sonnenrevolution übereinstimmen, sondern mit den Mondzyklen. Hier verstehen Sie jetzt, dass Sie durch die Wahl des YYYY.Y.Z-Versionierungsschemas gegenüber X.Y.Z eine dominante Kultur erzwungen haben.
  • Kleinere Veröffentlichungen bleiben unklar: Sie erwähnen “unter der Annahme einer monatlichen Kadenz”, aber es könnten auch 3 Wochen oder 7 sein, abhängig von der Funktionalität, in diesem Fall macht das Zählen von Y von 0 Sinn, oder streben Sie tatsächlich eine monatliche Veröffentlichung an, in diesem Fall wäre das Zählen von M von 1 sinnvoller?

Die Hauptänderung, die ich sehe, ist, dass das Discourse-Team durch die Einführung eines monatlichen Tempos Erwartungen setzt und sich von Release-Zielen entfernt, um stattdessen regelmäßige Veröffentlichungen zu fördern.

LTS für 8 Monate klingt nicht wirklich nach “lang”. NodeJS bewegt sich zu schnell, aber sie halten LTS-Support über 30 Monate und einige aktuelle Versionen gleichzeitig aufrecht, während Ubuntu LTS über Jahre hinweg beibehält. Obwohl ich verstehe, dass Discourse weder eine Sprache noch ein Betriebssystem ist, scheint es anzukündigen, dass neue Funktionalitäten in einem ziemlich schnellen Tempo ausgeliefert werden, was ein weiteres Problem aufwirft: Da immer wieder neue Admin-Einstellungen eingeführt werden, werden wir bald im WordPress-Höllenland mit unendlichen Optionen und unbegreiflicher Komplexität für die Website-Administration landen, auch bekannt als Bloatware: Es wird dann wichtig, zu klären, wie man von bestehenden Releases mit Zielen zu regelmäßigen Releases übergeht und wie man wählt, welche Ziele für eine Veröffentlichung fallen gelassen (oder verschoben) werden usw. (was möglicherweise bereits dokumentiert ist, aber das habe ich verpasst.)

Wären Sie so freundlich, Ihre Begründung für das Tempo der Entwicklung / Versionierung mitzuteilen und was Sie vorhaben, um zu vermeiden, dass Administratoren unter zu vielen Einstellungen und einer erhöhten Lernkurve ertrinken?

:heart: :discourse:

1 „Gefällt mir“
37

Bevor ich Ihre anderen Fragen beantworte, möchte ich zunächst klarstellen, dass sich unsere geplante Veröffentlichungsfrequenz mit diesem Vorschlag nicht ändert.

  • In den letzten 3 Jahren haben wir ungefähr alle 6 Monate „stabile“ Versionen veröffentlicht, die wir Ende Januar und Juli jedes Jahres anstrebten, mit geringfügigen Abweichungen:
  • In den letzten ca. 8 Monaten haben wir ungefähr monatlich „Beta“-Versionen veröffentlicht, abgesehen von ein paar außerplanmäßigen Sicherheitsupdates:

In diesem neuen Vorschlag beabsichtigen wir, das gleiche Tempo beizubehalten, das wir verfolgt haben. Die wichtigsten Änderungen sind:

  • Was wir jetzt „stabile“ Versionen nennen, werden wir „Versionen mit erweiterter Unterstützung“ nennen
    • Wir haben diesen Namen gewählt und nicht „Langzeitunterstützung“, weil wir zustimmen, dass sie im Verhältnis zu unseren anderen unterstützten Versionen „erweitert“ sind, aber nicht unbedingt „Langzeit“. Dieser Vorschlag beinhaltet nicht die Hinzufügung einer Langzeitunterstützungsversion.
    • Derzeit endet die Unterstützung für eine stabile Version sofort, wenn die nächste Version veröffentlicht wird. Mit diesem neuen Vorschlag überschneiden sich die Unterstützungszeiträume um ca. 2 Monate, sodass die Benutzer Zeit zum Upgrade haben und gleichzeitig Sicherheitspatches erhalten.
  • Was wir jetzt „Beta“-Versionen nennen, werden wir „Versionen“ nennen
    • Wir unterstützen Beta-Versionen über ihr Veröffentlichungsdatum hinaus derzeit überhaupt nicht. Sie sind lediglich Kontrollpunkte, die mit einer Benachrichtigung zum schnellen Vorwärtskommen einhergehen, da sie oft auch Sicherheitsfixes enthalten.
    • Mit diesem Vorschlag beabsichtigen wir, Versionen für ca. 2 Monate zu unterstützen, damit die Benutzer entscheiden können, wann sie upgraden möchten, und gleichzeitig weiterhin Sicherheitspatches erhalten.

Unter Berücksichtigung dessen, fühlen Sie sich, als ob Ihre anderen Fragen zu vielen Einstellungen immer noch mit diesem Vorschlag zusammenhängen? Oder sind es unabhängige Anliegen, die besser in einem separaten Thema besprochen werden sollten?

11 „Gefällt mir“
38

Vielen Dank für deine ausführliche Erklärung @mcwumbly!

In der Tat ist dies ein anderes Anliegen. Die Anpassung des Administrators mithilfe eines Plugins wäre nützlich, um Tests darüber durchzuführen, wie es aussehen könnte. Gibt es laufende Arbeiten in Bezug auf einen solchen Ansatz?

2 „Gefällt mir“
39

Nicht speziell dies, aber wir haben im letzten Jahr einiges in die Verbesserung der Admin-Oberfläche investiert. Wenn Sie sich damit näher befassen möchten, können Sie ein neues Thema eröffnen und einige der Probleme und/oder Ideen darlegen, die Sie weiter diskutieren möchten?

3 „Gefällt mir“
40

Dies ist eine großartige Änderung (ich mag besonders überlappende ESRs)

Feedback:

  1. Ich würde gerne sehen, dass der Lifecycle-Graph auf einer zentralen Seite angezeigt wird, damit ich ihn leicht überprüfen kann, idealerweise mit einer EOL-Tabelle, damit ich leicht erkennen kann, was sich jederzeit im und außerhalb des Supports befindet und entsprechend planen kann (zumindest für ESRs).

  2. Stream-Umschaltung:

Das wäre großartig – aber selbst die Möglichkeit, während der Einrichtung einen Tag auszuwählen, wäre riesig. Oder fügen Sie einfach die manuellen Schritte in die Setup-Dokumentation ein. Wenn jemand auf Stable/ESR beginnen möchte, ist es für einen neuen Administrator nicht klar, wie das im Moment geht. (Ich glaube, die Antwort ist --skip-rebuild an ./launcher zu übergeben, dann die Version zu bearbeiten und dann zum ersten Mal rebuild auszuführen, aber ich bin mir nicht sicher.) Da die Einrichtung sonst sofort mit dem Herunterladen und Ausführen der neuesten Version beginnt und ein Rückschritt Probleme verursacht.

(Beispiel für die Schwierigkeit für einen neuen Administrator: Derzeit leitet das Ergebnis Nr. 1 bei der Suche nach „Discourse Stable installieren“ zu diesem Thread weiter, der zu einem anderen Thread verlinkt, der erklärt, wie man auf Stable aktualisiert, aber nicht, wie man Stable von Grund auf installiert.)

2 „Gefällt mir“
42

Heute haben wir einen weiteren Schritt zur Implementierung dieses RFC unternommen – die neueste Version von Discourse trägt die Nummer v2025.11.0 :tada:

6 „Gefällt mir“