Weitere Informationen zu allen Änderungen in 2026.1 finden Sie unter:
Dies ist die erste „ESR“-Version von Discourse und ersetzt den alten „stable“-Zweig. Sites, die stable verfolgen, werden bei ihrem nächsten Upgrade von 3.5 auf 2026.1 aktualisiert. Um alle Änderungen von 3.5 bis 2026.1 anzuzeigen, verwenden Sie diesen Link.
Es wurden auch Patch-Versionen für andere unterstützte Versionen veröffentlicht:
2026.1.0 ist auch die erste esr-Version.
Für Benutzer des zuvor existierenden stable-Zweigs (der jetzt als esr bezeichnet wird), erfolgt der Wechsel von 3.5.3 auf 2026.1.0; und nicht auf 3.5.4.
Lassen Sie mich sehen, ich habe bis April Zeit, um nicht zu aktualisieren (3 Monate), wenn v2026.1 veraltet ist, wird meine aktuelle Version ESR sein, richtig? all diese Änderungen sind etwas verwirrend
Ja, es sei denn, sie verwenden das Tag v3.5.4, um bei 3.5 zu bleiben.
Das Diagramm auf der Startseite von https://releases.discourse.org/ ist der beste Weg, um sich die Dinge zu veranschaulichen.
Unabhängig davon, welchen Release-Zweig Sie wählen, müssen Sie für kritische Sicherheitspatches immer regelmäßig aktualisieren. Die Frage ist, ob Sie zusammen mit den Sicherheitspatches auch neue Funktionen und andere Änderungen übernehmen möchten (dann verwenden Sie release oder latest), oder ob Sie dafür eher einen ungefähr halbjährlichen Rhythmus bevorzugen (dann verwenden Sie esr).
Es ist noch früh für dieses neue Nummerierungsschema, daher werden sich die Dokumentation und die Tools weiterentwickeln, während wir uns in das neue System einleben.
Es war v2026.0, als ich das letzte Mal im Dezember aktualisiert habe, und jetzt v2026.2. Es wird im April ESR werden, richtig?
Sehen Sie sich die Homepage von releases.discourse.org an, um alle Support-Informationen zu erhalten. 2026.1 ist die aktuelle Extended-Support-Version und wird bis Oktober 2026 unterstützt.
2026.2 wird im Februar veröffentlicht und erhält zwei Monate lang Sicherheitskorrekturen. Es wird keine Extended-Support-Version sein.
Ist 2026.1.0 die erste stabile/ESR-Version, die die Unterstützung für iOS und andere alte Browser einstellt? Das ist eine so große Änderung, dass sie in den Versionshinweisen irgendwo aufgeführt werden sollte. Ich konnte dazu jedoch nichts in der Suchbox „detaillierte Änderungen“ am Ende finden.
Ach so, ich glaube, das liegt daran, dass Sie auf das Änderungsprotokoll für v2026.1.0-latest → v2026.1.0 verlinkt haben. Wenn Sie es auf v3.5.3 → v2026.1.0 ändern, werden 2397 detaillierte Änderungen angezeigt, anstatt nur 369. Für diese ESR-Versionen sollten Sie wirklich auf die letzte ESR-Version statt auf -latest verlinken (ist das so etwas wie eine RC?).
Ich kann immer noch nicht erkennen, welche Änderung das Einstellen der Unterstützung für die alten Browser eindeutig kennzeichnete, aber ich konnte zumindest diese finden: FIX: Update 'modern mobile' regex following iOS 15 support drop by davidtaylorhq · Pull Request #34792 · discourse/discourse · GitHub
Ja 
Stimmt. Die überwiegende Mehrheit der Benutzer verwendet die Streams latest oder release von Discourse, daher ist die Changelog-Website darauf optimiert. Benutzer, die sich für ESR entscheiden, „überspringen“ bei jedem Upgrade im Wesentlichen „5 Versionen“, sodass Sie sich die Änderungen für jede dieser Zwischenversionen ansehen müssten.
Sie können dies tun, indem Sie jede Zwischen-Changelog durchsuchen, oder Sie können die Filter verwenden, um eine benutzerdefinierte Changelog zu erstellen, die den gesamten Bereich abdeckt (wie Sie es getan haben). Vielleicht können wir die Benutzerfreundlichkeit der Release-Website verbessern, um eine Art Schnellverknüpfung für den Sprung zu einem ESR → ESR-Vergleich zu haben.
Wenn wir auf die letzte „stabile“ Version zurückblicken, hatten wir auch kein „Mega-Changelog“ dafür. Die Leute mussten jede der dazwischenliegenden Beta-Changelogs lesen, um ein vollständiges Bild der Änderungen zu erhalten. Ich denke also, wir bewegen uns in die richtige Richtung – zumindest ist es jetzt möglich, eine vollständige Changelog zu sehen, auch wenn die Benutzerfreundlichkeit nicht die beste ist.
Vorerst habe ich einen Link zu diesem ESR → ESR-Vergleich in den OP hier eingefügt:
Danke für das Feedback!
Ob von einer bestimmten Version zu einer anderen oder von einem beliebigen Punkt in latest zur neuesten latest, wenn eine Änderung zwischen den Commits x und y nicht durch das integrierte Updater-Programm angewendet werden kann und stattdessen ein Neuaufbau des Containers aus einem neuen Image erforderlich ist, wird das neue Release-Notes-System dies erkennen und auf die Notwendigkeit eines Neuaufbaus hinweisen?
Wird der integrierte Updater das Update separat verhindern und zum Neuaufbau auffordern?
Mein vages Verständnis des integrierten Updaters ist, dass er nach dem Aktualisieren von Docker_manager das Aktualisieren von Discourse blockiert, wenn ein Neuaufbau erforderlich ist. Ich habe dies jedoch nie formalisiert gesehen und anekdotisch schien es nicht vollständig zuverlässig zu sein.
Insbesondere wird manchmal nach Abschluss des Docker_manager-Updates beim Navigieren zur Versionsseite das Discourse-Update zum Starten angezeigt, und erst nach dem Aktualisieren der Seite wird es blockiert. [Ich möchte anmerken, dass das letzte Mal, als ich das gesehen habe, schon eine ganze Weile her ist, vielleicht wurde es behoben.]
Die Notwendigkeit eines Rebuilds hängt mit dem „Docker-Basisimage“ von Discourse zusammen, das vollständig von der Discourse-Versionsnummer entkoppelt ist. Wir benötigen es, wenn es kritische Änderungen an den Abhängigkeiten auf Betriebssystemebene innerhalb des Docker-Images gibt.
Es wäre also schwierig, dies in die Discourse-Kern-Release-Notes aufzunehmen. Aber ich verstehe, dass es überraschend/frustrierend ist, nicht über die Benutzeroberfläche (UI) aktualisieren zu können. Vielleicht können wir dort Verbesserungen an der Benutzeroberfläche vornehmen.
Ich könnte mir vorstellen, dass dies funktioniert durch:
Allerdings haben wir im Moment noch einige andere Dinge zu erledigen, die für die Versionierungsarbeit insgesamt wichtiger sind (z. B. die Kompatibilitätsprüfung für Theme-Komponenten/Plugins).
Oh, ich denke, es ist in Ordnung, nicht immer die Benutzeroberfläche für Updates verwenden zu können, und jeder (Einzelperson, Unternehmen oder was auch immer), der Discourse selbst hostet, muss jemanden mit zumindest grundlegenden Serveradministrationskenntnissen zur Verfügung haben, um Aufgaben wie die Aktualisierung des Hostsystems und das Neuerstellen von Discourse durchführen zu können.
Die wichtigsten Dinge in meinen Augen sind:
Solange sich die Benutzeroberfläche nach dem Aktualisieren von docker_manager immer korrekt aktualisiert, d. h. nicht in einem Zustand gerät, in dem sie weiß, dass docker_manager aktuell ist, aber nicht weiß, dass eine Neuerstellung erforderlich ist, denke ich, dass beides bereits zutrifft.