Weitere Informationen zu allen in 2026.7 veröffentlichten Änderungen findest du hier:
Auch für andere unterstützte Versionen wurden Patch-Releases veröffentlicht:
4 „Gefällt mir“
Wird dies zur aktuellen „esr“-Version, oder habe ich etwas missverstanden?
1 „Gefällt mir“
In der Tat kann ich nicht herausfinden, was passiert ist. Für dieses Update (sehr dringend aufgrund von Cache poisoning/XSS via color scheme cookies · Advisory · discourse/discourse · GitHub) war ein Neuaufbau erforderlich, aber da es ein v2026.1.5 → v2026.1.6 Changelog gab, ging ich davon aus, dass es sich um eine kleine Versionsnummer-Erhöhung handelt. Aber nein, jetzt bin ich bei v2026.7.0. Soweit ich weiß, ist mein Forum auf esr konfiguriert :
params:
db_default_text_search_config: "pg_catalog.english"
## Set db_shared_buffers to a max of 25% of the total memory.
## will be set automatically by bootstrap based on detected RAM, or you can override
db_shared_buffers: "2048MB"
## can improve sorting performance, but adds memory usage per-connection
db_work_mem: "40MB"
## Reduce max upload size
upload_size: 1m
## Which Git revision should this container use? (default: tests-passed)
version: esr
Ich war auch ziemlich überrascht, eine ganze Reihe von Post-Update-Abfragen wie diese zu sehen:
== 20260421061908 AddCoveringIndexOnChatMessagesThreadId: migrating ===========
-- remove_index(:chat_messages, {name: "idx_chat_messages_thread_id_id_user_id_not_deleted", algorithm: :concurrently, if_exists: true})2026-07-28 16:02:43.673 UTC [544] discourse@discourse LOG: duration: 16903.716 ms statement: CREATE INDEX CONCURRENTLY "index_posts_on_updated_at_for_localization" ON "posts" ("updated_at" DESC) WHERE deleted_at IS NULL AND user_id > 0 AND locale IS NOT NULL
2026-07-28 16:02:59.214 UTC [544] discourse@discourse LOG: duration: 15529.318 ms statement: CREATE INDEX CONCURRENTLY "index_posts_on_updated_at_for_locale_detection" ON "posts" ("updated_at" DESC) WHERE deleted_at IS NULL AND user_id > 0 AND locale IS NULL
2026-07-28 16:03:00.031 UTC [544] discourse@discourse LOG: duration: 798.943 ms statement: CREATE INDEX CONCURRENTLY "index_topics_on_updated_at_for_locale_detection" ON "topics" ("updated_at" DESC) WHERE deleted_at IS NULL AND user_id > 0 AND locale IS NULL
2026-07-28 16:03:00.186 UTC [544] discourse@discourse LOG: duration: 143.500 ms statement: CREATE INDEX CONCURRENTLY "index_topics_on_updated_at_for_localization" ON "topics" ("updated_at" DESC) WHERE deleted_at IS NULL AND user_id > 0 AND locale IS NOT NULL
2026-07-28 16:03:01.251 UTC [544] discourse@discourse LOG: duration: 1051.872 ms statement: UPDATE posts
SET raw = regexp_replace(
raw,
'\\+([_*~|`])(?=[^\]\[]*\]\(upload://)',
'\1',
'g'
)
WHERE id >= 1
AND id < 10001
AND raw ~ '\\+[_*~|`][^\]\[]*\]\(upload://'
2026-07-28 16:03:01.910 UTC [544] discourse@discourse LOG: duration: 658.965 ms statement: UPDATE posts
SET raw = regexp_replace(
raw,
'\\+([_*~|`])(?=[^\]\[]*\]\(upload://)',
'\1',
'g'
)
WHERE id >= 10001
AND id < 20001
AND raw ~ '\\+[_*~|`][^\]\[]*\]\(upload://'
2 „Gefällt mir“
Ja, genau!
Diese Version ist eine neue ESR-Version, also bist du beim Update darauf gewechselt.
3 „Gefällt mir“
Könnte das in Zukunft irgendwie weniger verwirrend gestaltet werden? Vielleicht liegt es nur an mir, aber wenn ein Update auf den ESR-Branch angewendet wird, auf dem ich mich gerade befinde, gehe ich davon aus, dass dies daran liegt, dass die aktuelle Hauptversion dieses Branches noch unterstützt wird.
2 „Gefällt mir“
2026.1 wird weiterhin unterstützt, und Sie können Ihre Installation darauf fixieren, indem Sie version: release/2026.1 in Ihrer app.yml festlegen. In diesem Fall hätte ein Neuaufbau das Sicherheitsupdate aus dem 2026.1-Branch übernommen.
Ich vermute, Sie haben version: esr verwendet? In diesem Fall verfolgen Sie die „neueste ESR“-Version, die jetzt 2026.7 ist.
Informationen zu den Unterstützungszeiträumen und den Überschneidungen zwischen ESR-Unterstützungen finden Sie unter https://releases.discourse.org/
Leider ist ein Downgrade von Discourse nicht möglich. Wenn Sie dies in Zukunft vermeiden möchten, können Sie auf release/2026.7 fixieren (und sicherstellen, dass Sie diese Fixierung manuell aktualisieren, bevor 2026.7 nicht mehr unterstützt wird).
1 „Gefällt mir“
Danke. Ich suche wohl nach der fehlersichersten/automatischsten Methode, um definitiv bei der ältesten noch unterstützten Version zu bleiben, also dem langsamsten Entwicklungspfad.
3 „Gefällt mir“
Bei mir ist es genauso, und ich glaube, esr (fast) macht das. Alle paar Monate gibt es ein neues esr, und du wechselst darauf, was gerade passiert ist. Aber tatsächlich hat das alte esr noch zwei Monate Wartungszeit, also erwartest du, auf dem vorherigen esr zu bleiben. (Ich denke, das ist eine vernünftige Erwartung. Brauchen wir ein esr-maintained-Label??)
4 „Gefällt mir“
Ich finde, das ist eine vernünftige Überlegung, aber denk auch darüber nach … was wäre in zwei Monaten anders, wenn v2026.1 nicht mehr gepflegt wird?
Ohne weitere Änderungen würdest du zu diesem Zeitpunkt weiterhin „ohne Vorwarnung“ aktualisiert werden.
Ist das in Ordnung?
1 „Gefällt mir“
Ja, ich denke, es ist immer noch sinnvoll, länger an der alten ESR-Version festzuhalten. Das bedeutet, dass die neue ESR-Version bereits getestet wurde und möglicherweise einige Fehlerbehebungen enthält.
Ich habe die neue ESR innerhalb einer Stunde aktualisiert und bereue es etwas: In der heutigen Welt wäre es am besten, an der vorherigen Version zu bleiben und nur die Sicherheitsupdates zu installieren. Dies entkoppelt die dringenden Sicherheitsupdates vom administrativen Lernprozess und von neuen Fehlern, die in Kürze behoben werden. Siehe den sehr hilfreichen Beitrag
Wechsel von 2026.1 ESR zu 2026.7 – Meine Erfahrungen
(Warum sollte man neue Fehler in einer frisch veröffentlichten ESR erwarten? Weil, soweit ich das beurteilen kann, die neue ESR bis zum Veröffentlichungszeitpunkt in kontinuierlicher Entwicklung war. Es gibt keine Stabilisierungsphase.)
2 „Gefällt mir“
Das ist die große Frage.
Wenn ich also auf esr-maintained wäre, wären nach zwei Monaten esr und esr-maintained derselbe Branch, oder? Also würde ich nach zwei Monaten immer noch von der großen Änderung überrascht sein.
Solange esr und esr-maintained nicht derselbe Branch sind, könnte Discourse eine Warnung ausgeben/anzeigen, dass du den „ESR-Gnadenzeitraum“ betreten hast. Diese Warnung könnte nur im Forum für Admins angezeigt werden, und nicht beim Neuaufbau des Containers.
Eine Vorabinformation über den ESR-Rollover wäre schön, damit du das Upgrade während dieses unterstützten Gnadenzeitraums planen und testen kannst.
4 „Gefällt mir“
In einer idealen Welt gibt dir das zwei Monate Zeit, um deinen Staging-Server auf das neue ESR zu aktualisieren, während du in der Produktionsumgebung das alte ESR mit Sicherheitsupdates weiterlaufen lässt, um diesen Zeitraum abzudecken.
Es macht tatsächlich Sinn, eine Art einfache Kennzeichnung zu verwenden, um das gepatchte alte ESR zu verfolgen, sodass du die Wartungsupdates des alten ESR automatisch erhältst.
Vielleicht gibt es dafür bereits eine Möglichkeit?
2 „Gefällt mir“
Ich glaube nicht, dass der ESR-Kanal so viele Fehlerbehebungen erhalten wird. Genau wie 2026.1 – ab jetzt werden nur noch Sicherheitsupdates bereitgestellt.
Das bedeutet also, dass zwar einige dieser Fehler innerhalb eines Monats bekannt sein könnten, aber es heißt nicht, dass du dich nicht damit auseinandersetzen musst.
3 „Gefällt mir“
Um pessimistisch zu sein: Wir werden sehen! Ich nehme an, wenn es in einer frisch gebackenen ESR (Extended Stable Release) einen dummen Breaking Change geben würde, wäre dieser behoben. Vielleicht ist diese neue Welt noch nicht lange genug etabliert, um das zu sehen. Tatsächlich würde ich keine Fixes für bloße Unannehmlichkeiten erwarten.
1 „Gefällt mir“