Je rejoins ce que d’autres ont dit, j’aime la direction des changements proposés. Et je pense que les noms de branches proposés sont beaucoup plus intuitifs que les anciens 
Ce qui n’est pas encore tout à fait clair pour moi, c’est comment le processus de mise à niveau fonctionnera pour les branches release et esr (la branche latest semble simple). Vous mentionnez qu’à chaque instant, la version actuelle (n) et la version précédente (n-1) seront prises en charge, et qu’en tant qu’administrateur, j’aurai le choix de la mise à niveau.
D’après mon expérience avec d’autres logiciels, lorsqu’une nouvelle version (n+1) arrive, je suis informé de sa disponibilité. Et je peux alors décider de faire une mise à niveau majeure (équivalente à par exemple apt dist-upgrade sous Linux) ou une mise à jour mineure/standard (équivalente à par exemple apt upgrade sous Linux) et rester sur la version n. Est-ce quelque chose qui sera intégré au script du lanceur Discourse ?
De plus, je comprends le désir de minimiser la cérémonie/le processus de publication, mais mon intuition serait que les versions normales et ESR reçoivent au moins un peu de tests supplémentaires avant d’être publiées. Cela pourrait être dû au fait que j’ai trop longtemps travaillé dans l’informatique d’entreprise 
Enfin, je me demande si les publications mensuelles ne sont pas en fait “trop rapides”. C’est certes subjectif, mais d’après ma propre expérience dans la gestion d’infrastructures informatiques en tant que bénévole, je n’aurai peut-être pas le temps d’effectuer des mises à jour majeures chaque mois. Et partant de là, je me demandais si vous ne pourriez pas également vous simplifier la vie en tant que développeurs de Discourse en publiant simplement trimestriellement, et en n’ayant pas de branches esr séparées, mais uniquement des branches release.