Mit den aktuellen Launcher-Tools und dieser neuen Branch-Struktur könnten Sie die Upgrade-Zeit wie folgt steuern:
- v2026.02 veröffentlicht
- Sie setzen
version: release/v2026.02in Ihrer app.yml-Datei - v2026.03 veröffentlicht
- Sie führen einen Rebuild durch. Sie erhalten immer noch 2026.02 mit allen aktuellen Sicherheitspatches
- Wenn Sie bereit sind, wechseln Sie in der app.yml zu
version: release/v2026.03
Aber das manuelle Bearbeiten dieser app.yml jeden Monat ist wirklich nicht ideal, daher hoffen wir, dass wir ein System entwickeln können, das den Prozess benutzerfreundlicher macht.
Der Prozess in der OP erlaubt es uns, die Branches als “Release Candidates” zu behandeln, bevor wir sie tatsächlich als Release kennzeichnen. Ich bin mir in diesem Stadium nicht sicher, ob und wie wir diese Funktion nutzen werden – ich denke, das wird sich entwickeln, wenn wir uns an das neue System gewöhnen.
Wir versuchen hier, ein Gleichgewicht zwischen der Geschwindigkeit der Discourse-Entwicklung und der Stabilität für Personen mit umfangreichen Anpassungen zu finden. Eine Verzögerung von mehr als 3 Monaten, um Funktionen für unsere Kunden verfügbar zu machen, ist keine Option. Wenn überhaupt, ist monatlich für uns eher langsam. Derzeit beabsichtigen wir immer noch, latest für die Mehrheit unseres Hostings zu verwenden.
Aber für diejenigen, die Discourse selbst hosten, verstehe ich natürlich den Wunsch nach selteneren Änderungen. Hier kommen also die ESR-Releases ins Spiel.