La realidad aquí es que la rama estable es una LTS, y bastante buena además. Recibe actualizaciones de seguridad y está bastante claro qué versiones de plugins son compatibles con ella (gracias al archivo .discourse-compatibility). Admito totalmente que tardó mucho tiempo antes de que todo esto empezara a funcionar, pero en los últimos dos años más o menos, lo ha hecho, lo cual es un gran logro del equipo.
Ahora, para la segunda parte de tu declaración. Es cierto que stable a menudo se representa como algo que no deberías querer. Pero en el hosting de Communiteq, hemos estado dando a los clientes la libre elección entre estable (“estabilidad primero, nuevas actualizaciones dos veces al año, actualizaciones de seguridad una vez al mes”) y tests-pasados (“siempre al límite, nuevas funciones una vez al mes”) durante los últimos 2,5 años y el 85% elige estar en estable.
Lo entiendo. ¿Pero no es eso un problema de desarrollo y no un problema de producción? Puedo entender totalmente que lo hagas en desarrollo. Pero añadir esos plugins en una instalación de producción por defecto va un poco en contra de la idea de tener un plugin (que por definición es algo no predeterminado).
La única ventaja real en producción que veo es el problema muy, muy marginal de desinstalar plugins y hosts multisitio. (De nuevo, ¡esto es algo bueno, todos los demás problemas de producción se han resuelto con el tiempo!)
Eso también podría haberse resuelto en el script de configuración mostrando una lista de plugins que los usuarios pueden marcar y luego añadiéndolos a app.yml.
Pero todavía ofrecéis diferentes (sub)conjuntos de plugins para diferentes niveles, ¿verdad?