Von Discourse 3.2: Hinzufügen des Suffixes -dev zu Beta-Versionen in aktiver Entwicklung

Bei tests-passed wird ab 3.2.0.beta1-dev die Discourse-Kernversionsnummern ein -dev-Suffix enthalten, um anzuzeigen, dass es sich nicht um die endgültigen „Release“-Versionen eines Beta handelt. Dieses Suffix erscheint nicht in der Benutzeroberfläche, daher ist dies eine Formalität, die keine Auswirkungen auf die überwiegende Mehrheit der Benutzer haben wird.

Die technischen Details finden Sie unten:


In der Beta-Serie für Discourse 3.1 und darunter bestand unsere Versionierungsstrategie darin, eine Beta-Version zu „veröffentlichen“ und dann die Versionsnummer in tests-passed bis zur nächsten Beta-Veröffentlichung unverändert zu lassen. Dies hatte einige Probleme:

  1. Bei dem Versuch, eine Version anzugeben, konnte eine Version wie 3.1.0.beta2 Hunderte von möglichen Zeitpunkten bezeichnen. Dies ist besonders problematisch, wenn versucht wird, die Kompatibilität präzise zu definieren über .discourse-compatibility-Dateien.

  2. Nach einer Hauptversion mussten wir sofort „beta1“ der nächsten Version „veröffentlichen“, um die Entwicklung auf tests-passed fortzusetzen. Deshalb hatten wir redundante beta1-Veröffentlichungen.

Um die Situation zu verbessern, werden wir nun während der Entwicklung einer Beta-Version -dev an die Versionsnummer anhängen. Wir beginnen also zum Beispiel den Entwicklungszyklus 3.2 mit 3.2.0.beta1-dev. Wenn diese Version zur Veröffentlichung bereit ist, wird sie als 3.2.0.beta1 gekennzeichnet, und dann werden wir sofort mit einem weiteren Commit fortfahren, um die Entwicklung von 3.2.0.beta2-dev zu starten.

Zukünftig sollen „Hauptveröffentlichungen“ etwa so aussehen:

    %%{init: { 'logLevel': 'debug', 'gitGraph': {'showBranches': true, 'showCommitLabel':true,'mainBranchOrder': 2}} }%%
    gitGraph
       branch stable order: 1
       commit tag: "v3.1.8"
       checkout main
       commit id: "bump to v3.2.0.beta17" tag: "v3.2.0.beta17" type: HIGHLIGHT
       commit id: "bump to v3.2.0.beta18-dev"
       commit
       commit id: "bump to v3.2.0.beta18" tag: "v3.2.0.beta18" type: HIGHLIGHT
       checkout stable
       merge main id: "merge"
       commit id: "bump to v3.2.0" type: HIGHLIGHT tag: "v3.2.0"
       checkout main
       commit id: "bump to v3.3.0.beta1-dev"

„Nebenveröffentlichungen“ sehen etwa so aus:

    %%{init: { 'logLevel': 'debug', 'gitGraph': {'showBranches': true, 'showCommitLabel':true,'mainBranchOrder': 2}} }%%
    gitGraph
       branch stable order: 1
       commit tag: "v3.1.1"
       checkout main
       commit id: "bump to v3.2.0.beta2-dev"
       commit id: "... development of beta2 ..."
       commit id: "bump to v3.2.0.beta2" tag: "v3.2.0.beta2" type: HIGHLIGHT
       checkout stable
       commit id: "backports"
       commit id: "bump to v3.1.2" type: HIGHLIGHT tag: "v3.1.2"
       checkout main
       commit id: "bump to v3.2.0.beta3-dev"

(In diesen Diagrammen können „main“ und „tests-passed“ als gleichwertig betrachtet werden.)

Diese Prozesse wurden in einigen Rake-Aufgaben kodifiziert, die Sie in version_bump.rake finden können.

31 „Gefällt mir“

Es erscheint auf der /admin-Seite… aber das Auffinden dieses Themas hat mich beruhigt.

1 „Gefällt mir“

Wenn allein die Versionsnummerierung so komplex ist (ihr zuzuweisen und von Benutzern wie mir verstanden zu werden), wie komplex wäre dann die Softwareentwicklung!!!

Nachdem ich etwa 15 Minuten über all diese Beta-, Stable-, Dev-, Tests-bestanden-, Backuporting-Sachen nachgedacht habe, habe ich schließlich aufgegeben.

Was zum Teufel! Meine Website soll weiterhin ‘Dev’ anzeigen!!