Concordo con quanto detto da altri, mi piace la direzione delle modifiche proposte. E penso che i nomi dei branch proposti siano molto più intuitivi di quelli vecchi 
Ciò che non mi è ancora del tutto chiaro è come funzionerà il processo di aggiornamento per i branch release e esr (sembra che latest sia semplice). Menzioni che, in ogni momento, saranno supportate sia la release corrente (chiamiamola n) sia la release precedente (n-1), e che, come amministratore, avrò la possibilità di scegliere quando aggiornare.
Ora, basandomi sulla mia esperienza con altri software, quando arriva una nuova versione di release (n+1), sarei avvisato della disponibilità della versione n+1. E potrei quindi decidere di fare un aggiornamento maggiore (equivalente ad esempio a apt dist-upgrade su Linux) o fare un aggiornamento minore/standard (equivalente ad esempio a apt upgrade su Linux) e rimanere alla versione n. È qualcosa che verrà integrato nello script del launcher di Discourse?
Inoltre, capisco il desiderio di ridurre al minimo la cerimonia/processo di rilascio, ma la mia intuizione sarebbe che sia i rilasci normali che quelli esr ricevano almeno un po’ di test aggiuntivi, prima di essere rilasciati. Questo potrebbe derivare dal fatto di aver lavorato troppo a lungo nell’IT aziendale, però 
Infine, mi chiedo se i rilasci mensili siano in realtà “troppo veloci”. Ammetto che anche questo è soggettivo, ma a giudicare dalla mia esperienza nella gestione di cose IT come volontario, potrei non avere il tempo per aggiornamenti più importanti ogni mese. E partendo da questo, mi chiedevo se poteste anche semplificarvi la vita come sviluppatori di Discourse rilasciando semplicemente trimestralmente, e non avendo branch esr separati, ma solo branch release.