Aktualisieren/Neuerstellen des Docker Containers ergibt v3.5.2 statt v2025.11.0

Installation
1

Wir haben eine bestehende Discourse-Installation aktualisiert, so wie wir es schon mehrmals zuvor getan haben: Nachdem wir die aktuelle Revision des discourse_docker-Repositorys gezogen haben, führen wir den folgenden Befehl aus:

./launcher rebuild app

Er läuft ohne Fehler durch und startet auch den neuen Container – sieht alles gut aus.

Aber bei der Untersuchung des HTML-Quellcodes der laufenden Anwendung stellen wir fest, dass sie immer noch behauptet, v3.5.2 zu sein (die Version vor dem Update) – anstelle der erwarteten v2025.11.0.

Unser Vorgehen ist dasselbe wie bei früheren Updates. Das Einzige, was sich offensichtlich geändert hat, ist das Nummerierungsschema für Versionen, das mit v2025.11.0 eingeführt wurde – vielleicht hängt es mit dieser Änderung zusammen?

Ich habe überprüft, ob die Versionszeichenfolge im Discourse-Quellcode z. B. vergessen wurde, hochgezählt zu werden, aber das ist nicht der Fall, siehe die beiden Commits:

Aus der Ausgabe des rebuild-Befehls des Launchers habe ich bemerkt, dass er einen git pull durchführt und die neuen Branches sieht/erkennt:

(...)
 t [tag update]          beta                    -> beta
 t [tag update]          latest-release          -> latest-release
 * [new tag]             release                 -> release
 * [new tag]             v2025.11.0              -> v2025.11.0
 * [new tag]             v2025.12.0-latest       -> v2025.12.0-latest
 * [new tag]             v3.5.2                  -> v3.5.2
 * [new tag]             v3.6.0.beta2            -> v3.6.0.beta2
Switched to a new branch 'stable'
I, [2025-12-03T12:27:14.785550 #1]  INFO -- : branch 'stable' set up to track 'origin/stable'.

Trotzdem fühlt es sich irgendwie so an, als würde er den falschen (im Sinne von „nicht den neuesten“) Branch auswählen. Der „stable“-Branch scheint v3.5.2 zu enthalten (laut lib/version.rb in diesem Branch).

Ich habe die Release-Ankündigung für 2025.11.0 erneut gelesen, und das klingt tatsächlich nach einem stabilen Release, nicht nur nach einer Vorschau-/Early-Adopter-Version. Die verlinkte neue Versionierungsstrategie erwähnt den latest-Branch, aber ich bin jetzt nicht weniger verwirrt, was ich erwarten soll.

Übersehe ich etwas? Oder können wir beeinflussen, welche Version beim Rebuild ausgewählt wird? Oder funktioniert es im Moment einfach nicht wie beabsichtigt und das Rebuild-Tooling muss geändert werden?

Ich bin mir nicht sicher, ob das zusammenhängt, aber auf Docker Hub ist der „latest“-Tag 3.5.2 – und numerisch absteigend sortiert könnte dies der neueste Tag für eine lange Zeit sein…

1 „Gefällt mir“
2

v3.5.x ist die korrekte Version für den stabilen Zweig :+1:

2025.11.0 ist ein monatliches „Release“, aber kein „stabiles“/„esr“-Release. (Wir werden „stable“ bald in „esr“ umbenennen, als Teil der neuen Versionierungsstrategie)

1 „Gefällt mir“
3

Das ist verwirrend. Es wäre sinnvoller, alle gleichzeitig auf das neue Versionsschema umzustellen, aber es ergibt auch keinen Sinn, dass Stable ein Upgrade durchführt, wenn es kein neues Stable gibt. Ich war verwirrt, und ich denke, ich achte auf diese Dinge. Ich erinnere mich jetzt an eine Diskussion mit Richard darüber, aber ich habe nicht genau genug zugehört, um es zu verstehen.

:person_shrugging:

4

Danke @david – das hilft zumindest insofern, als ich jetzt verstehe, dass ich nichts falsch gemacht habe.

Nun bleibt für uns das Problem, wie wir entscheiden, was ein „monatliches Release“ und was ein „stabiles Release“ ist?

Wir rufen den Atom-Feed von Github ab (um über neu erkannte Releases benachrichtigt zu werden), und dort erscheinen 2025.11.0 und 3.5.2 auf die gleiche Weise (zusammen mit vielen anderen Tags).

Wie/wo können wir also leicht herausfinden, was die Absicht Ihres Teams für ein bestimmtes Versionstag ist?

Ich stimme @pfaffman hier zu, es ist im Moment sehr verwirrend.

5

Ja, ich verstehe – wir befinden uns in einer Übergangsphase zwischen zwei Nummerierungs-/Benennungsschemata, daher ist es etwas schwierig, den Überblick zu behalten.

Wir arbeiten daran, eine Seite zu erstellen, die alle derzeit unterstützten Versionen und deren Änderungsprotokolle auflistet. Etwas in der Art von dieser. Hoffentlich hilft das bei Fragen wie diesen.

Ab Januar 2026 werden wir eine Veröffentlichung mit dem Tag „esr“ kennzeichnen. Dies wird der Ersatz für den 6-monatigen Rhythmus der aktuellen „stabilen“ Version sein.

Also wurde beta zu release (es war nie wirklich „beta“, sondern nur ein monatlicher Kontrollpunkt)

Und stable wird zu esr, aber das ist noch nicht geschehen.

Wenn Sie also einen 6-monatigen Rhythmus wünschen, sollten Sie sich vorerst an stable halten und ab Januar esr verwenden.

Wenn Sie einen monatlichen Rhythmus wünschen, können Sie auf das Tag release abzielen.