La réalité est que la branche stable EST une LTS, et plutôt une bonne d’ailleurs. Elle reçoit des mises à jour de sécurité et il est assez clair quelles versions de plugins y sont compatibles (grâce au fichier .discourse-compatibility). J’admets totalement qu’il a fallu beaucoup de temps avant que tout cela ne fonctionne, mais ces deux dernières années environ, c’est le cas – ce qui est une grande réussite de l’équipe.
Passons à la deuxième partie de votre déclaration. Il est vrai que stable est souvent présenté comme quelque chose à éviter. Mais chez Communiteq hosting, nous donnons depuis 2 ans et demi aux clients le libre choix entre stable (« la stabilité avant tout, nouvelles mises à jour deux fois par an, mises à jour de sécurité une fois par mois ») et tests-validés (« toujours à la pointe, nouvelles fonctionnalités une fois par mois ») et 85% choisissent la version stable.
Je comprends. Mais n’est-ce pas un problème de développement et non un problème de production ? Je peux tout à fait comprendre que vous fassiez cela en développement. Mais ajouter ces plugins dans une installation de production par défaut va un peu à l’encontre de l’idée d’avoir un plugin (qui est par définition quelque chose de non-défaut).
Le seul avantage réel en production que je vois est le problème très, très marginal de désinstaller des plugins et des hôtes multisites. (Encore une fois, c’est une bonne chose, tous les autres problèmes de production ont été résolus au fil du temps !)
Cela aurait également pu être résolu dans le script d’installation en affichant une liste de plugins que les utilisateurs peuvent cocher, puis en les ajoutant à app.yml.
Mais vous proposez toujours différents (sous-)ensembles de plugins pour différents niveaux, n’est-ce pas ?