Discourse liefert keine LTS-Version aus

Allgemein
1

Ich war mir der Kompatibilität von Discourse nicht bewusst, daher werde ich mich damit beschäftigen müssen.

Ich möchte dies ansprechen, da es so klingt, als gäbe es eine große Diskrepanz zwischen der Art und Weise, wie das Discourse-Team “stabil” versteht, und der Art und Weise, wie der Rest der Discourse-Community/größeren Forum-Administratoren-Community Discourse’s stabiles Angebot versteht.

Hauptgründe, warum stabil nicht der Definition von LTS entspricht.

1) Stabil wird von Mitarbeitern aktiv abgeraten, wann immer es angesprochen wird

Ich möchte nicht unbedingt einzelne Poster hervorheben, aber hier ist eine Auswahl von Beiträgen von Mitarbeitern, um das Thema zu verdeutlichen:

Beachten Sie, dass tests-passed in gewisser Weise stabiler ist als stable, da es das ist, was discourse.org verwendet, also ist es am besten getestet.

Discourse befindet sich also in einem permanenten Beta-Zustand, was bedeutet, dass wir immer an neuen Funktionen und Verfeinerungen arbeiten. In unserem Fall bedeutet Beta nicht instabil; wir hosten Websites mit Millionen von Seitenaufrufen pro Monat auf unseren Tests-bestanden und Beta-Versionen.

Der stabile Kanal ist nicht unbedingt “stabiler” als tests-passed. Es geht mehr um die Idee, dass die Fehler bekannt sind und er als Kontrollpunkt für eine bestimmte Reihe von Funktionen und Verbesserungen dient. Mit tests-passed können neue Fehler eingeführt und dann einige Commits später behoben werden.

Die Botschaft war ziemlich konstant, dass Discourse sich in einer “permanenten Beta” befindet, was nicht die Erfahrung ist, die Produktions- / Nicht-Entwickler-Benutzer wünschen.

Bei einer schnellen Suche auf DuckDuckGo der Top-Ten-Links für Discourse-Stable scheint keiner davon wirklich für die Verwendung von Stable zu plädieren. Unabhängig von seiner tatsächlichen Qualität, wenn Mitarbeiter die Leute universell von Stable abraten, hat es einen negativen Eindruck in den Köpfen der Menschen, als ob es nicht zweckmäßig wäre.

Stable mag großartig sein, aber wenn uns immer wieder gesagt wird, dass es am besten ist, es nicht zu verwenden, werden wir es nicht für ernsthafte Bereitstellungen in Betracht ziehen.

2. Ein LTS erhält Fehlerbehebungen, die über reine Sicherheitsfehlerbehebungen hinausgehen

Ein LTS ist etwas, das keine Funktions-Upgrades erhält, aber Fehlerbehebungen erhält. Laut den Kommentaren der Mitarbeiter scheint es in Discourse keine Anstrengungen zu geben, Fehlerbehebungen für Nicht-Sicherheitsfehler zurückzuportieren. Vielleicht stimmt das nicht, aber das wurde uns gesagt.

3. Ein LTS hat unkomplizierte Installationsschritte

Die Installationsanleitung erwähnt nicht einmal die Existenz von Stable.

4. Ein LTS wird weithin genutzt

Vor Ihrem Beitrag hatte ich noch nichts von einer weit verbreiteten Nutzung des stabilen Zweigs gehört. Wird er auch im Feld weit verbreitet genutzt? Angesichts der Tatsache, wie versteckt er ist, bezweifle ich es, aber ich habe keine Metriken, um das zu sagen. Dies ist ein wichtiger Faktor, da er den Leuten Vertrauen gibt, Stable für ihre Produktionsbereitstellungen zu nutzen.

5. Ein LTS hat einen klaren Veröffentlichungszyklus und Upgrade-Hinweise

Ich sehe keine zentrale Stelle, an der Stable klar dokumentiert ist. (Vielleicht übersehe ich es ja nur!)

Meine Erwartungen an ein LTS sind eine Seite, die Folgendes beschreibt:

  • Aktuelle aktive Release-Version
  • Release Notes einschließlich:
    • Wichtige Änderungen/Funktionen zwischen LTS-Versionen
    • Migrationsschritte von der letzten LTS-Version (insbesondere zu beachtende Breaking Changes)
    • Geplante aktive Support-Dauer für jede Version

z.B. mediawiki, aber wirklich jedes wichtige Open-Source-LTS hat ähnliche Seiten.

Diese Dokumentation hilft mir, wenn es eine Breaking Change gibt, die Ausfallzeiten und/oder manuelle Eingriffe erfordert.

6. Ein LTS hat keine größeren Breaking Changes innerhalb eines Release-Zyklus

Dies mag für Stable zutreffen, aber ich bin zu sehr daran gewöhnt, auf den Upgrade-Button zu klicken und das Forum geht offline, um es sicher zu wissen. Ich suche hier wahrscheinlich nach klareren Warnungen, wenn man zwischen Versionen wechselt, die etwas kaputt machen.

7. Ein LTS bietet API-Deprecations-Warnungen für mindestens einen vollständigen LTS-Release-Zyklus

Diese sollten in der Größenordnung eines Jahres oder mehr gemessen werden, im Gegensatz zu einem Monat oder mehr.

8. Ein LTS ist gestaffelt / hat überlappende Support-Zeiträume

Jedes große LTS hat eine überlappende Support-Periode zwischen zwei LTS-Versionen. Stable scheint einfach einen binären Wechsel zur nächsten Version zu machen. (Meine Einschätzung kann auch falsch sein, da es keine zentrale Dokumentationsseite gibt)

9. Es ist unkompliziert, von Non-LTS auf LTS zu aktualisieren

Es gibt keine Notwendigkeit, Rückwärtskompatibilität zu unterstützen, aber wenn ein LTS verfügbar ist, ist es nicht klar, wie man sauber auf LTS wechselt. Es sieht so aus, als gäbe es einige Beiträge im Forum dazu, aber wieder keine zentralisierte Dokumentation, die ich finden konnte.

Ich bin ein Fan von Discourse, aber dies ist ein häufiger Schmerzpunkt, sowohl für mich als auch für viele andere. Was Stable im Moment ist, ist nur ein Zweig, kein LTS.

4 „Gefällt mir“
2

Dies wurde in ein eigenes Thema verschoben, da es nichts mit dem Bündeln von Plugins zu tun hat.

3 „Gefällt mir“
3

Wenn wir das traurige Gesicht im Admin-Dashboard betrachten, im Vergleich dazu, dass wir bei „Update Discourse“ so viele Commits zurückliegen
ist der kritische Update-Teil Teil von tests-passed und wenn Sie nach dem traurigen Gesicht sofort auf „Alle aktualisieren“ klicken, sind Sie mit tests-passed synchron.

4

Ich glaube, dieses spezielle Update erfordert zweimaliges Neuerstellen von der Konsole.

1 „Gefällt mir“
5

Discourse scheint eine ziemlich hohe Änderungsgeschwindigkeit und eine ehrgeizige Roadmap zu haben.

Um dies zu unterstützen, benötigt es viel Benutzerfeedback. Ich denke, es gibt eine klare implizite Strategie zur Förderung von tests-passed, da dies frühes Feedback zu neuen Änderungen unterstützt.

Im Gegenzug erhält der Benutzer kostenlose Software und neue Funktionen. Es ist eine Art Pakt. Ich denke, im Laufe der Zeit hat sich dieser Deal als erfolgreich erwiesen.

Ein stabiler Build hilft der Entwicklung nicht wirklich weiter, daher ist es möglicherweise nicht im geschäftlichen Interesse, ihn so stark zu fördern (nur meine Meinung, ich spreche überhaupt nicht für CDCK).

Das andere Problem mit Stable ist dieses, und es ist sogar noch bedeutender:

Zwischen stabilen Versionen gibt es normalerweise viele Änderungen, darunter erhebliche Stilllegungen und API-Änderungen. Die Beteiligung an tests-passed als Entwickler, Website-Administrator oder Theme-Ersteller gibt Ihnen die Möglichkeit, Änderungen in kleinen, überschaubaren Schritten anzugehen, anstatt jedes Mal einen riesigen Berg zu erklimmen, wenn Sie den nächsten stabilen Meilenstein erreichen.

Um diese großen Sprünge zu unterstützen, benötigen Sie wahrscheinlich eine Staging-Website und eine Reihe von Testfällen, die Sie durchgehen können.

Wenn Sie selbst keine Anpassungen besitzen, könnten Sie sich für Stable entscheiden, aber Sie verlassen sich stark auf andere, über die Sie möglicherweise keinen starken Einfluss haben, um sicherzustellen, dass alle von Ihnen verwendeten Add-ons für Ihr nächstes Upgrade ausreichend gepflegt werden. Möglicherweise stellen Sie fest, dass einige Elemente die Unterstützung verlieren, bis es Zeit für ein Upgrade ist, und zu diesem Zeitpunkt könnten Sie sich in einer Zwickmühle befinden. Möglicherweise stellen Sie auch fest, dass der Entwickler Stable überhaupt nicht unterstützt und Sie müssen einen Fork erstellen und einen „Cut“ des Plugins vorbereiten, um Ihren stabilen Build zu unterstützen. (Es gibt jedoch ein gutes Pinning-System, sodass es keine riesige Menge an Arbeit ist)

Das andere wichtige Merkmal von Discourse ist, dass es sehr stark auf Unit-Tests ausgerichtet ist, sodass der tests-passed-Branch normalerweise aus Stabilitätssicht sehr gut ist.

4 „Gefällt mir“
6

Angesichts der Weigerung des Managements, unpopuläre Änderungen wie die Plugin-Bündelung rückgängig zu machen, glaube ich nicht, dass dieser Teil zutrifft. Vielleicht aus QA-Sicht, aber selbst dann gab es mehrere ziemlich knifflige Fehler, die in der Vergangenheit nicht behoben wurden. Letztendlich verstehe ich, dass sie diejenigen sind, die Zeit und Geld darin investieren, also dürfen sie ihre Entscheidungen treffen, aber meiner Meinung nach glaube ich nicht, dass es eine Strategie ist, mehr Feedback zu erhalten.

Ich denke, der realistischere Grund, warum sie kein richtiges LTS unterstützen, ist, dass es jemanden im Team Zeit für die Verwaltung/Dokumentation kosten würde. Es ist eine Funktion, die hauptsächlich Self-Hostern zugutekommt, daher stelle ich mir vor, dass sie als Zeitfresser für sie angesehen würde. Aber es ist eine erwartete Funktion, und das Fehlen davon ist ein echter Nachteil, wenn Forum-Administratoren ihre Forum-Software auswählen, da andere Zeitgenossen stabilere Angebote haben.

7

Im Gegenteil, ich denke, die Bündelung von Plugins dient gerade dazu, deren Nutzung zu fördern und infolgedessen mehr Feedback zu erhalten.

8

Das Management hat insbesondere Probleme mit Versionsinkonsistenzen angesprochen, die die Produktivität des Entwicklungsteams im anderen Thread beeinträchtigen. Dies ist eine faire Begründung, aber nicht der ideale Weg, um das Grundproblem zu lösen, wie im anderen Thread besprochen.