Es gibt keine formelle Definition von „verifiziert“, die mir bekannt ist.
Jegliche Software ist potenziell fehlerhaft.
tests-passed hat die aktuellsten Commits. beta erhält nur Beta-Releases. stable erhält nur stabile Releases.
tests-passed läuft auf praktisch allen von discourse.org gehosteten Seiten und der überwiegenden Mehrheit der selbst gehosteten Seiten.
@mcwumbly – Haben wir ein Dokument „Welche Version soll ich ausführen“? Ich habe ein wenig gesucht und nichts gefunden. Alles, woran ich mich erinnere, ist etwas Ähnliches aus den stable-Ankündigungen.
Wir sollten auch den Unterschied zwischen Builds erklären und wie man den Build, auf dem man sich befindet, in den Installationsanweisungen https://github.com/discourse/discourse/blob/main/docs/INSTALL-cloud.md ändert. Ich habe es gerade überflogen und sehe keine Erwähnung davon.
Ich habe dies (ich glaube, es ist das erste Mal, dass ich das getan habe!) abgetrennt, da die arme Seele immer noch nicht sagen kann, ob es “gefährlich” ist, ein Upgrade durchzuführen, und diese Diskussion darüber, wie das Problem gelöst werden kann, dass die Leute nicht wissen, ob sie ein Upgrade durchführen sollen, nicht hilft.
Vielleicht ist Is Discourse always in "beta"? das, wonach ich gesucht habe (aber vergessen habe, dass es da war, um danach zu suchen).
Die andere Sache, nach der er gefragt hat, und wo er angefangen hat, und ich denke, ist ziemlich vernünftig, ist: “Wenn ich auf der neuesten Beta bin, warum sollte ich dann ein Upgrade durchführen müssen?” Und das oben behandelt das ziemlich direkt.
Ich glaube nicht, dass wir das tun sollten. Wir möchten, dass die Leute auf tests-passed sind. Die offiziellen Installationsanweisungen sollten zu einer Standardinstallation mit möglichst vielen Einstellungen führen, die unseren Wünschen entsprechen. Dazu gehört auch der Branch, der verfolgt wird.
Es wird immer Leute geben, die sich entscheiden, z. B. die neueste stabile Version zu verwenden. Wenn es keinen Leitfaden gibt, wie sie das am intuitivsten erreichen können, verschwinden diese Leute nicht; es macht die Dinge für sie nur ein wenig weniger bequem – und bedeutet wahrscheinlich manchmal, dass sie hierher kommen, um zu fragen, und andere Zeit damit verbringen, die Frage zu beantworten (immer und immer wieder).
Das stärkere Argument ist jedoch wahrscheinlich, dass der Leitfaden ihnen zeigen kann, wie sie es richtig machen, was bedeutet, dass sie später zurückwechseln können, wenn sie ihre Meinung ändern. Wenn sie es nicht wissen, könnten sie ihre Installation beschädigen, was sowohl für sie als auch für ihre Community unbequem ist.
Wenn INSTALL-cloud.md einen Abschnitt zum Wechseln des Branches enthält, kann dies verdeutlichen, was der Standard ist und warum, und klarstellen, dass der Standard am weitesten verbreitet und am einfachsten zu unterstützen ist.
Ich bin zu 100 % damit einverstanden, dass es auf Meta eine Anleitung gibt, wie man Branches wechselt. Ich glaube nur nicht, dass sie in die offizielle Installationsanleitung gehört, wo 95 % der Leute sich nicht darum kümmern oder kümmern müssen.
Wenn Basic Bob versucht, Discourse zu installieren, möchte er die Installation so schnell und einfach wie möglich abschließen, damit er an seiner neuen Website arbeiten kann. Informationen zum Wechseln von Branches werden ihn nur zum Nachdenken anregen und Verwirrung stiften.
Advanced Ally hingegen ist möglicherweise daran interessiert zu verstehen, wie Branches funktionieren und welcher für ihre Website am besten geeignet ist. Aber sie recherchiert wahrscheinlich auch mehr, bevor sie Discourse installiert, und geht nicht einfach die Installationsanleitung durch.
Tatsächlich gibt es gelegentlich Themen von Benutzern, die zu Beta oder Stable zurückkehren möchten und dabei fehlschlagen.
Wenn dies in die Standardinstallationsdokumentation aufgenommen wird, würden sich die Fluttore öffnen, sowohl aufgrund der oben genannten Probleme als auch aufgrund von Kompatibilitätsproblemen mit Plugins bei älteren Versionen.
Ich stimme zu. Alles in allem habe ich das Gefühl, dass beta die Leute mehr verwirrt, als dass es einen Nutzen erfüllt.
Ich denke, es hilft, dort zwischen Dingen zu unterscheiden, die man benutzt und die intern eine Bedeutung haben, und Dingen, die für Dritte eine Bedeutung haben. Der beta-Zweig ist ein gutes Beispiel dafür. Obwohl er vielleicht einen internen Nutzen hat, hat er wenig Nutzen für Dritte und verwirrt sie manchmal.
Ich wäre daran interessiert, anderes zu hören, aber wenn ich jetzt darüber nachdenke, kann ich mich nicht an einen ernsthaften Self-Hostter erinnern, der beta in irgendeiner sinnvollen Weise tatsächlich verwendet. „Basic Bob“ weiß nicht wirklich, was ein Branch ist und kümmert sich wahrscheinlich nicht darum (und das ist auch in Ordnung). „Advanced Ally“ wird tests-passed verwenden, wenn sie eine Einzelperson oder ein KMU ist, und möglicherweise stable (oder Commits anheften), wenn sie ein mittelständisches oder großes Unternehmen ist.
Mein Vorschlag wäre, alles branch-mäßig genau so zu belassen, wie es ist, aber öffentlich zu sagen: „Wir haben zwei Branches, die Sie verwenden können: tests-passed (der Standard und beste) und stable (wenn Sie wissen, was Sie tun, und einen bestimmten Bedarf haben).“
Von meiner Seite aus wäre es schon eine Verbesserung, wenn der Branch-Name tests-passed neben dem Versionsnamen auf dem Dashboard sichtbar wäre.
Absolut einverstanden. Jeder, der einen anderen Branch nehmen möchte, wird ihn fast immer finden.
Wenn sie ihn mit den vorhandenen Ressourcen (Suche, Standard-GitHub-Projekt) nicht finden können, sind sie dann wirklich mit den Fähigkeiten ausgestattet, die nötig sind, um den Unterschied zwischen den Branches vollständig zu verstehen, geschweige denn vom Standard abzuweichen?
Sicher, das ergibt Sinn. Aber ich habe das Gefühl, dass wir eine Gelegenheit verpassen, den Leuten zu helfen, den Unterschied zwischen den verschiedenen Optionen hier zu verstehen. Ich sehe keinen Nachteil darin, Self-Hostern zu sagen, dass der Standard tests-passed ist, was für die meisten Websites ideal ist und sicherstellt, dass Sie die neuesten Sicherheitsfixes und Updates erhalten. Wenn Sie risikoscheu sind, können Sie es bei tests-passed belassen und nur dann aktualisieren, wenn Sie dazu aufgefordert werden, oder etwa eine Woche, nachdem Sie die Aufforderung erhalten haben. Auf diese Weise entdecken andere Leute zuerst eventuelle Probleme und diese werden behoben, bevor Sie aktualisieren.
Gibt es angesichts der oben genannten Punkte legitime Gründe für Self-Hoster, von tests-passed zu wechseln? Ich schätze, wenn Ihre Website stark modifiziert ist und kaputt geht, wenn der Kern-Diskurs oder offizielle Plugins aktualisiert werden, und Sie sich selbst oder Ihren Administratoren nicht zutrauen, nicht zu aktualisieren? Oder wenn Sie eine Entwicklungs- oder Staging-Umgebung einrichten?
Ein weiterer Ort, an dem dies erklärt werden könnte, ist in app.yml, das derzeit ziemlich kryptisch ist, da es sich nur auf tests-passed bezieht und die Optionen oder wann Sie zu einer anderen wechseln könnten, nicht erwähnt.
## Welche Git-Revision soll dieser Container verwenden? (Standard: tests-passed)
#version: tests-passed
Meiner Meinung nach ist die Verwendung von etwas anderem als tests-passed nur dann sinnvoll, wenn Sie einen Managed-Hosting-Service nutzen oder: 1) wenn ein Team Ihre Community verwaltet (d. h. Sie sind ein mittelständisches bis großes Unternehmen); und 2) Sie einen bestimmten Grund haben, nicht auf tests-passed zu sein, z. B. wenn Sie mehrere benutzerdefinierte Anpassungen haben, die kaputt gehen könnten.
Ich würde sagen, dass beide Bedingungen notwendig sind, denn wenn Sie kein Team haben, das Ihre Community im Szenario mit mehreren fragilen Anpassungen verwaltet, ist Ihr Problem nicht die Verwendung Ihres Branches, sondern Ihr allgemeines Website-Management (d. h. es ist nicht nachhaltig).
Selbst wenn beides zutrifft, gäbe es zuerst andere Dinge zu berücksichtigen, wie z. B. Ihre Update-Richtlinie.
Ich denke, das Problem ist, dass, wenn Sie etwas sagen würden wie „Sie können stable oder tests-passed verwenden“, einige Leute stable dort einfügen würden, weil es „vernünftig“ klingt, obwohl sie es wahrscheinlich nicht verwenden sollten.
Wohin mit Beta?
Um die Argumentation gegen den beta-Branch zu untermauern, sind die Hauptverwirrungen, die er in verschiedenen schriftlichen und gesprochenen Kontexten hervorruft:
Leute assoziieren den Begriff „Beta“ normalerweise mit etwas, das mehr an der Spitze ist als der „Standard“. Hier nicht der Fall.
Einige Unternehmen erwägen die Verwendung, da es etwas weniger an der Spitze als tests-passed und etwas aktueller als stable erscheint, d. h. es scheint wieder „vernünftig“. Aber in den meisten Fällen ist es keine gute Idee.
„beta“ ist ein Begriff, der sowohl in Discourse-Versionsnummern als auch als Discourse-Branch-Name verwendet wird. Ich habe festgestellt, dass dies einige Leute verwirrt.
„Beta“ schreckt wahrscheinlich einige semi-computer-affine Leute wie mich ab – die übliche Bedeutung ist „noch auf Qualität testen“ und nicht „noch Funktionen hinzufügen“.
Ich denke dabei wahrscheinlich eher an die Versionsnamen als an den Branch-Namen. Ich war davon ausgegangen, dass ich mich auf einem „Beta“-Branch befinde, basierend auf den Versionsnamen (was ich nicht bin), bis ich es jetzt überprüft habe, also hat mich nichts davon abgeschreckt…
Ja. Ich denke, es ist verwirrend (oder ich sehe, wie es verwirrend sein könnte), dass man sich auf tests-passed befindet und die Version als „Beta“ angezeigt wird, man aber ein Upgrade durchführen und neuen Code erhalten kann, der dieselbe Beta-Version ist, auf der man sich bereits befindet. Und es gibt Wochen und Hunderte von Commits zwischen Beta-Releases.
