Die Realität ist, dass die stabile Version ein LTS ist, und zwar ein ziemlich gutes. Sie erhält Sicherheitsupdates und es ist ziemlich klar, welche Plugin-Versionen damit kompatibel sind (dank der .discourse-compatibility-Datei). Ich gebe zu, dass es lange gedauert hat, bis das alles funktionierte, aber in den letzten etwa zwei Jahren hat es funktioniert – was eine großartige Leistung des Teams ist.
Nun zum zweiten Teil Ihrer Aussage. Es ist tatsächlich so, dass stable oft als etwas dargestellt wird, das man nicht haben möchte. Aber bei Communiteq Hosting bieten wir seit 2,5 Jahren Kunden die freie Wahl zwischen Stable („Stabilität zuerst, neue Updates zweimal im Jahr, Sicherheitsupdates einmal im Monat“) und Tests-bestanden („immer am Puls der Zeit, neue Funktionen einmal im Monat“) und 85 % entscheiden sich für Stable.
Das verstehe ich. Aber ist das nicht ein Entwicklungsproblem und kein Produktionsproblem? Ich kann durchaus verstehen, dass Sie das in der Entwicklung tun. Aber diese Plugins in eine Standard-Produktionsinstallation aufzunehmen, untergräbt die Idee, ein Plugin zu haben (das per Definition etwas Nicht-Standardmäßiges ist).
Die einzige tatsächliche Produktionsvorteil, den ich sehe, ist das sehr, sehr Randproblem des Deinstallierens von Plugins und Multisite-Hosts. (Auch hier ist das eine gute Sache, alle anderen Produktionsprobleme wurden im Laufe der Zeit gelöst!)
Das hätte auch im Setup-Skript gelöst werden können, indem eine Liste von Plugins angezeigt wird, die Benutzer auswählen können, und diese dann zu app.yml hinzugefügt werden.
Aber Sie bieten immer noch unterschiedliche (Teil-)Sets von Plugins für verschiedene Stufen an, richtig?