Wechseln zwischen Discourse-Release-Kanälen / -Versionen

[Discourse]

Dieser Leitfaden erklärt, wie Sie den Release-Kanal Ihrer Discourse-Instanz konfigurieren.

Erforderliches Benutzerlevel: Systemadministrator

Konsolenzugriff ist erforderlich.

Die Verwaltung des Kanals Ihrer Discourse-Instanz bestimmt die Häufigkeit und Art der Updates, die Sie erhalten. Dieser Leitfaden erklärt die verfügbaren Kanäle und bietet einen schrittweisen Ansatz zum Ändern des Branches in Ihrer Einrichtung.

Zusammenfassung

Discourse bietet mehrere Kanäle zum Verfolgen von Software-Updates: latest, release und esr. Diese Dokumentation erklärt den Zweck jedes Kanals, seine wichtigsten Funktionen und wie Sie sie in Ihrer Discourse-Instanz konfigurieren. Für eine Illustration der Kanäle siehe releases.discourse.org.

Unterstützte Kanäle

latest

Empfohlene Standardeinstellung
Dieser Kanal bietet die neuesten Fehlerkorrekturen und Kompatibilitätsupdates für Plugins. Jeder übergebene Commit vom main-Branch wird vom Build-Server getestet und nach erfolgreicher Überprüfung dem latest-Branch hinzugefügt.

• Geeignet für Sites, die auf dem neuesten Stand bleiben möchten.
• Sites können manuell jederzeit aktualisiert werden.

release

Für Sites, die monatliche Releases bevorzugen

Der release-Kanal verfolgt das neueste monatliche Release von Discourse. Jeden Monat wird ein Release-Branch (z. B. release/2026.2) aus latest erstellt, der einen stabilen Snapshot bereitstellt.

• Ca. einmal pro Monat veröffentlicht.
• Jedes Release erhält kritische Fehlerkorrekturen für zwei vollständige Release-Zyklen.

esr

Extended Support Release

Das esr-Tag verfolgt das neueste Extended Support Release, das für Sites gedacht ist, die langfristige Stabilität und Sicherheit gegenüber häufigen Updates priorisieren.

• Ca. alle 6 Monate aus den monatlichen Releases deklariert.
• Erhält Sicherheitsupdates und kritische Backports über einen längeren Zeitraum.
• Kann eine begrenzte Kompatibilität mit Community-Plugins und Theme-Komponenten aufweisen.

Hinweis: Das Nicht-Empfangen regulärer Wartungsupdates kann dazu führen, dass einige Funktionen veraltet oder optisch inkonsistent sind.

Veraltete Aliase

Aus Gründen der Abwärtskompatibilität funktionieren die folgenden alten Branch-/Tag-Namen weiterhin, gelten jedoch als veraltet:

• tests-passed → latest
• beta → release
• stable → esr

Andere Branches oder Referenzen

Das Verfolgen anderer Branches (z. B. spezifischer release/YYYY.M-Branches oder Commit-SHAs) ist möglich, erfordert jedoch Fachkenntnisse. Diese Branches erhalten nur für einen begrenzten Zeitraum kritische Fehlerkorrekturen.

Anweisungen zur Konfiguration Ihres Kanals

Führen Sie diese Schritte aus, um den gewünschten Branch in Ihrer Discourse-Instanz zu konfigurieren:

1. Zugriff auf die Konfigurationsdatei
   Öffnen Sie die Konfigurationsdatei app.yml, indem Sie die folgenden Befehle in Ihrer Konsole ausführen:

cd /var/discourse
nano containers/app.yml

Der nano-Editor öffnet die Konfigurationsdatei.
2. Bearbeiten des Tracking-Branches
Suchen Sie den Versionsparameter, indem Sie nach dem Wort „version“ in der Datei suchen:

params:  
## Welche Git-Revision soll dieser Container verwenden? (Standard: latest)  
#version: latest

• Kommentieren Sie die Versionszeile aus.
• Ersetzen Sie latest durch Ihren gewünschten Branch- oder Tag-Namen (z. B. esr). Beispiel:

params:  
## Welche Git-Revision soll dieser Container verwenden? (Standard: latest)  
version: esr  

3. Speichern und Beenden

• Drücken Sie Ctrl+O, um Ihre Änderungen zu speichern.
• Drücken Sie Enter, um zu bestätigen.
• Verwenden Sie Ctrl+X, um den Editor zu verlassen.

4. Container neu erstellen
   Sobald die Änderungen vorgenommen und gespeichert wurden, erstellen Sie den Container neu, um die neue Konfiguration anzuwenden:

./launcher rebuild app

Das Neuerstellen führt zu einer vorübergehenden Ausfallzeit

[ghorbani (Aref)]

@Discourse

cd /var/discourse
git pull
nano containers/app.yml

Ist git pull ein notwendiger Schritt, oder ist er überflüssig und stammt aus der veralteten Dokumentation, ähnlich wie beim Aktualisieren von Discourse (Manuell Discourse und Docker-Image auf die neueste Version aktualisieren)?

[merefield (Robert)]

Aus meiner Erfahrung ist git pull gelegentlich nützlich – z. B. ein absolutes Muss, als wir von yarn zu pnpm gewechselt haben …

Normalerweise muss man sich bei einem regulären Rebuild keine Gedanken darüber machen.

[ghorbani (Aref)]

Gut zu wissen! Vielen Dank für die Information.

[merefield (Robert)]

Was ich normalerweise mache, ist, es neu aufzubauen. Wenn es aus einem nicht ganz offensichtlichen Grund fehlschlägt, versuche ich zuerst ein git pull – das dauert nur einen Moment.

[david (David Taylor)]

Theoretisch sollte dies niemals erforderlich sein. Der Launcher erkennt automatisch eine veraltete Kopie und führt selbstständig git pull aus:

launcher

[ghorbani (Aref)]

Vielen Dank für die Details. In der Tat ergibt das Sinn. Ich werde es einmal ohne git pull versuchen und dir Bescheid sagen, wie es läuft.

[Ed_S]

Das ist seltsam. Der fragliche Code stammt aus dem Jahr 2015, mein Forum aus dem Jahr 2018, und doch bin ich mir ziemlich sicher, dass es hier mehrere Fälle gab, in denen ein git pull nötig war.

Ich mache auf jeden Fall immer ein git pull, wenn ich daran denke – es kostet mich nichts.

[david (David Taylor)]

Es wird oft erwähnt, ich denke wegen dieser sehr historischen Dokumente. Ich glaube nicht, dass ich jemals Beweise dafür gesehen habe, dass es tatsächlich hilft.

Aber ja, es schadet nicht, es auch manuell auszuführen

[Ed_S]

@Discourse

## Welche Git-Revision soll dieser Container verwenden? (Standard: latest)  
#version: latest

Da die yml-Datei version und nicht supported tracking branch verwendet, wäre es sinnvoll, (version) zum Themen-Titel hinzuzufügen?

[ghorbani (Aref)]

Das Datum hat mich anfangs auch etwas schockiert. Aber beim Überprüfen der Versionshistorie stellt sich heraus, dass das letzte Update vom 18. Mai stammt.

[david (David Taylor)]

Ich habe versucht, den Eröffnungspost so zu aktualisieren, dass unsere moderne Terminologie mit „Kanal“ verwendet wird, und einige unnötige Verweise auf git pull entfernt.

[merefield (Robert)]

Es muss mindestens einen Randfall geben, denn in sehr seltenen Fällen hat es mich definitiv „über den Berg“ gebracht.

Könnte es sein, wenn sich das Hauptskript unter bestimmten Bedingungen ändert?