Hallo,
Hier ist die Idee, die mir immer wieder durch den Kopf geht: Die meisten Frustrationen bezüglich der “neue Version bei jedem Commit verfügbar”-Meldung entstehen daraus, dass der latest-Kanal sich kontinuierlich aktualisiert. Daher ist es eigentlich der normale Ruhezustand, ein paar Commits hinterherzuhinken, aber die Seite behandelt dies so, als wäre etwas falsch. Anstatt das Ganze neu zu entwerfen, würde ich mich darauf konzentrieren, Signale von Rauschen zu unterscheiden.
So stelle ich mir das vor: Die Seite hat einen Statusbanner, dessen Bedeutung davon abhängt, wo man sich tatsächlich befindet:
- Auf dem neuesten Stand → unauffällig, positiv, keine Aufforderung zum Handeln.
- Ein paar Commits hinter
latest→ grau/informativ, und es steht explizit keine Aktion erforderlich. Dies ist der Zustand, der aktuell „schreit“ und das wirklich nicht sollte. - Eine neue monatliche Version ist unterwegs (z. B.
v2026.8.0) → prominent, mit einem Link zu den Veröffentlichungshinweisen. - Sicherheitsupdate → rot/dringend, separat hervorgehoben.
Nur die letzten beiden sollten so wirken, als müsste man darauf reagieren.
Ein paar weitere Dinge, die ich dort gerne sehen würde:
- Die Versionsnummer wieder prominent in der Mitte. Einfach eine kleine Karte mit der installierten Version, dem Commit-Hash und dem Kanal (z. B.
v2026.8.0-latest.1 · dfe770d · latest). Das ist die häufigste Beschwerde, die ich gesehen habe, und sie ist einfach wiederherzustellen. - Nutzung des bereits vorhandenen zwischengespeicherten Checks. Der Versionscheck läuft bereits als periodischer Sidekiq-Job, nicht live pro Anfrage. Daher sollte die Seite nicht langsam wirken – sie kann das zwischengespeicherte Ergebnis sofort mit einer Zeile „zuletzt vor X Minuten geprüft“ und einem manuellen „Jetzt prüfen“-Button anzeigen, anstatt beim Laden neu zu berechnen.
- Ein Update-Verlauf mit Links zu den Änderungsprotokollen – im Grunde die ursprüngliche Idee in diesem Thema. Eine kurze Zeitleiste der Releases (monatlich + ESR), wobei jedes auf sein Änderungsprotokoll oder Diff verweist.
Zu Komponenten und Neuaufbauten: Was ich am deutlichsten gemacht sehen möchte, ist die Unterscheidung zwischen Updates, die der Web-Updater selbst anwenden kann (Kern + Plugins, via git pull), und solchen, die den Container ändern und daher ./launcher rebuild app auf der Kommandozeile erfordern. Eine pro Komponente aufgelistete Übersicht, in der jede Zeile zeigt, zu welcher Kategorie sie gehört, wäre sehr hilfreich. Für den Neuaufbau-Fall könnte das exakte Kommando mit einer Kopier-Schaltfläche angezeigt werden, anstatt man raten zu lassen.
Zu Plugin-Kompatibilität: Der Mechanismus .discourse-compatibility behandelt bereits den Fall, in dem dein Kern älter ist als das, was ein Plugin jetzt anspricht – er checkt während eines Neuaufbaus stillschweigend den letzten kompatiblen Commit dieses Plugins aus. Das betrifft hauptsächlich Stable/ESR-Installationen, und heute geschieht es stillschweigend. Es wäre schön, dies als einfache informative Zeile „auf einer kompatiblen Version gehalten“ anzuzeigen, damit Admins älterer Releases sehen, warum ein Plugin nicht auf seinem neuesten Commit ist. (Der umgekehrte Fall, dass ein Plugin noch keine neuere Kernversion unterstützt, wird heute nicht wirklich behandelt; es gibt einen offenen Feature-Request bezüglich min/max kompatibler Versionen, der dies abdecken würde.)
Ich habe schnell einen interaktiven Mockup erstellt, um zu sehen, wie die verschiedenen Zustände nebeneinander wirken – ehrlich gesagt ist der größte Gewinn einfach der Zustand „du hinkst, aber das ist in Ordnung“. Sobald dieser kein Alarm mehr ist, wird die Seite wieder wirklich nützlich. Gerne teile ich den Mockup, wenn jemand ihn ausprobieren möchte.