Bis jetzt habe ich erkannt, dass es einen stabilen Kanal gab und ich die Konfiguration bearbeiten muss, um zu ihm zu wechseln.
Ich sehe jetzt eine Upgrade-Option für meine Websites auf 3.0.0.beta16. Wenn ich jetzt auf die stabile Version umstelle und ein Upgrade durchführe, wird es dann auf 3.0.0.beta16 und schließlich auf 3.0.0 stabil aktualisiert?
Können Sie erklären, warum Sie glauben, dass Sie zu stabil wechseln müssen?
Ich bin mir nicht sicher, warum man jemals einen Grund brauchen sollte, stabile Software auszuführen. Ich möchte einfach weniger Updates und stabile Software.
Ich glaube nicht. Wenn Sie zu stable wechseln, werden Sie nur auf Hauptversionen aktualisieren, und 3.0.0 wurde noch nicht veröffentlicht. Die letzte stabile Version war 2.8.0 (die neuesten Updates finden Sie in release-notes).
Ich glaube nicht, dass Stephen versucht hat, witzig zu sein. Stable wird als Schlüsselwort für app.yml verwendet, nicht als englisches Wort. Der Grund dafür ist, dass das andere (Standard-)Schlüsselwort, tests-passed, ebenfalls als stabil beschrieben werden kann: Es ist unwahrscheinlich, dass es kaputt geht[1], und tatsächlich kann es “stabiler” (im englischen Sinne) sein, wenn Sie Plugins und/oder Theme-Komponenten häufiger aktualisieren, als Sie Discourse aktualisieren möchten.
in meinen 2 Jahren mit Discourse hatte ich nie eine Situation, in der etwas wegen eines neuen Commits kaputt ging ↩︎
Danke für die Info! Ich weiß, dass er nicht versucht hat, lustig zu sein, er wollte nur keine Begründungen diskutieren, sondern nur Informationen darüber, wann man auf stabil aktualisieren kann. Ich werde weiterhin aktualisieren, solange es heißt, und sobald ich sehe, dass 3.0.0 stabil ist, werde ich wechseln.
Seien Sie sich bewusst, dass die Veröffentlichung der Hauptversion, meines Wissens nach, auf einem Tests-bestanden-Zweig von der Veröffentlichung von n+1.beta1 begleitet wird. Wenn Sie also das Wort „beta“ in Ihrer Version vermeiden möchten, sollten Sie darauf wechseln, kurz bevor Sie auf n+1.beta1 aktualisieren.
Manchmal[1] werden die Fragen auf der Grundlage fehlerhafter Annahmen formuliert, und es ist besser, diese frühzeitig zu verstehen.
man könnte argumentieren, ziemlich oft, wenn wir uns mit „Bitte helfen Sie mir“-Themen befassen. Dies basiert meiner bescheidenen Meinung nach auch auf Diskussionen in meinem Forum ↩︎
Ich bin also jetzt zum Beispiel bei 2.9.0.beta14. Soll ich den Branch in meiner Konfiguration auf stable umstellen und dann einfach warten, bis 3.0.0 in meinem /admin-Bereich angezeigt wird, und er zeigt dann nur noch Updates auf stabile Versionen an?
Muss ich den Docker-Container neu starten, wenn ich die Konfigurationsdatei ändere?
Sie können die app.yml jetzt ändern. Sie müssen warten, bis die Veröffentlichung erfolgt, um einen weiteren Befehl zur Aktualisierung der Befehlszeile auszuführen. Es ist nicht klar, wie viele weitere Beta-Versionen vor der Veröffentlichung einer neuen stabilen Version erscheinen werden.
Stabil bedeutet weniger Updates, aber nicht unbedingt weniger Fehler. Es erfordert etwas mehr Fachwissen, um stabil zu laufen, als Tests zu bestehen. Kritische Sicherheitsupdates werden in stabilen Versionen berücksichtigt, aber UX-Probleme bleiben wahrscheinlich bis zur nächsten stabilen Veröffentlichung bestehen. Drittanbieter-Plugins funktionieren mit dem stabilen Branch wahrscheinlich weniger gut, da er weniger gut getestet ist.
Wenn Sie weniger Updates wünschen, können Sie einfach seltener aktualisieren.
Eine gute Erklärung von Stable vs. Test-Passed:
Ich muss zugeben, dass ich mich durch die Update-Benachrichtigung auf der Admin-Seite unter Druck gesetzt und verwirrt fühle.
Sie fordert mich ziemlich abrupt auf, sofort zu aktualisieren, aber sie fordert mich auf, auf Beta-Software zu aktualisieren. Das ist ziemlich widersprüchlich. Ich denke, sie sollte den Benutzer darüber informieren, dass es ein Update gibt, aber den Benutzer nur dann drängen, so schnell wie möglich zu aktualisieren, wenn es ein Sicherheitsproblem oder einen kritischen Fehler in der aktuellen Version gibt.
Vielleicht könnte das Beta-Tag entfernt werden, wenn es als stabil erachtet wird, oder es könnte in tests-passed geändert werden, damit Administratoren sich mit dem Update wohler fühlen und wissen, dass sie vollständig getestete und stabile Software erhalten.
Alternativ könnte das Beta-Tag weggelassen und es als stabil bezeichnet werden, da das, was ich hier lese, darauf hindeutet, und die aktuelle stabile Version könnte als LTS bezeichnet werden.
Genau das passiert, wenn eine neue Betaversion herauskommt, gibt es (fast immer) ein ernstes Sicherheitsproblem, das die neue Version auslöst.
Das wäre in der Tat eine ziemlich gute (meiner Meinung nach bessere) Sichtweise.