Ich stimme dem, was andere gesagt haben, zu. Mir gefällt die Richtung der vorgeschlagenen Änderungen. Und ich denke, die vorgeschlagenen Branch-Namen sind viel intuitiver als die alten 
Was mir noch nicht ganz klar ist, ist, wie der Upgrade-Prozess für die release- und esr-Branches funktionieren wird ( latest scheint unkompliziert zu sein). Sie erwähnen, dass zu jedem Zeitpunkt sowohl die aktuelle Version (nennen wir sie n) als auch die vorherige Version (n-1) unterstützt werden und dass ich als Administrator die Wahl habe, wann ich ein Upgrade durchführe.
Basierend auf meiner Erfahrung mit anderer Software würde ich benachrichtigt, wenn eine neue Release-Version (n+1) eintrifft. Und ich könnte dann entscheiden, ob ich ein Major-Upgrade durchführe (entspricht z.B. apt dist-upgrade unter Linux) oder ein Minor/Standard-Update durchführe (entspricht z.B. apt upgrade unter Linux) und bei Version n bleibe. Ist das etwas, das in das Discourse-Launcher-Skript integriert wird?
Außerdem verstehe ich den Wunsch, die Release-Zeremonie/den Prozess auf ein Minimum zu beschränken, aber meine Intuition wäre, dass sowohl normale als auch ESR-Releases zumindest etwas zusätzliche Tests erhalten, bevor sie veröffentlicht werden. Das mag aber auch daran liegen, dass ich zu lange im Enterprise-IT-Bereich gearbeitet habe 
Schließlich frage ich mich, ob monatliche Releases tatsächlich “zu schnell” sind. Das ist zugegebenermaßen auch subjektiv, aber nach meiner eigenen Erfahrung bei der Verwaltung von IT-Sachen nebenbei als Freiwilliger habe ich möglicherweise nicht die Zeit für größere Updates jeden Monat. Und ausgehend davon habe ich mich gefragt, ob Sie vielleicht auch Ihr Leben als Entwickler von Discourse etwas einfacher gestalten könnten, indem Sie einfach vierteljährlich veröffentlichen und keine separaten esr-Branches haben, sondern nur release-Branches.