La realtà qui è che il ramo stabile è un LTS, e anche piuttosto buono. Riceve aggiornamenti di sicurezza ed è abbastanza chiaro quali versioni dei plugin sono compatibili con esso (grazie al file .discourse-compatibility). Ammetto totalmente che ci è voluto molto tempo prima che tutto ciò iniziasse a funzionare, ma negli ultimi due anni circa, ha funzionato, il che è un grande risultato per il team.
Ora per la seconda parte della tua affermazione. È effettivamente vero che stable è spesso rappresentato come qualcosa che non dovresti volere. Ma su Communiteq hosting, da 2,5 anni offriamo ai clienti la libera scelta tra stabile (“stabilità prima, nuovi aggiornamenti due volte all’anno, aggiornamenti di sicurezza una volta al mese”) e test-superati (“sempre all’avanguardia, nuove funzionalità una volta al mese”) e l’85% sceglie di essere su stabile.
Lo capisco. Ma non è un problema di sviluppo e non un problema di produzione? Posso capire totalmente che lo stai facendo in fase di sviluppo. Ma aggiungere quei plugin in un’installazione di produzione predefinita vanifica l’idea di avere un plugin (che per definizione è qualcosa di non predefinito).
L’unico reale beneficio di produzione che vedo è il problema molto, molto marginale di disinstallare plugin e host multisito. (Di nuovo, questa è una buona cosa, tutti gli altri problemi di produzione sono stati risolti nel tempo!)
Ciò avrebbe potuto essere risolto anche nello script di configurazione mostrando un elenco di plugin che gli utenti possono selezionare e quindi aggiungerli a app.yml.
Ma offrite ancora diversi (sotto)insiemi di plugin per diversi livelli, giusto?