다른 분들의 의견에 동의합니다. 제안된 변경 사항의 방향성이 좋습니다. 또한 제안된 브랜치 이름이 기존 이름보다 훨씬 직관적이라고 생각합니다. 
아직 명확하지 않은 점은 release와 esr 브랜치(latest는 직관적으로 보입니다)의 업그레이드 프로세스가 어떻게 작동하는지입니다. 말씀하신 대로, 시점마다 현재 릴리스(이를 n이라고 하겠습니다)와 이전 릴리스(n-1)가 모두 지원되며, 관리자로서 언제 업그레이드할지 선택할 수 있다고 하셨죠.
다른 소프트웨어를 사용해 본 제 경험에 비추어 보면, 새 릴리스 버전(n+1)이 나올 때 버전 n+1의 사용 가능 여부를 알리는 알림을 받습니다. 그리고 그 후 메이저 업그레이드(Linux의 apt dist-upgrade와 유사)를 수행하거나, 마이너/표준 업데이트(Linux의 apt upgrade와 유사)를 수행하여 버전 n에 머물러 있을지 결정할 수 있었습니다. 이것이 Discourse 런처 스크립트에 구현될 기능인가요?
또한, 릴리스 의식/프로세스를 최소화하려는 의도는 이해하지만, 제 직관으로는 일반 릴리스와 ESR 릴리스 모두 출시 전에 최소한 추가 테스트를 거치기를 원합니다. 이는 엔터프라이즈 IT 분야에서 일한 기간이 너무 길어서 그런 편견일 수도 있습니다. 
마지막으로, 월간 릴리스가 실제로는 “너무 빠르지는” 않은지 궁금합니다. 이는 인정하건대 주관적인 의견이기도 하지만, 부업으로 IT 업무를 관리하는 자원봉사자로서의 제 경험을 볼 때, 매월 큰 업데이트를 처리할 시간이 없을 수도 있습니다. 그리고 그 점을 고려해 볼 때, Discourse 개발자로서 여러분의 업무를 좀 더 쉽게 만들어 주려면 분기별로만 릴리스하고, 별도의 esr 브랜치 없이 release 브랜치만 유지하는 것도 하나의 방법이 될 수 있지 않을까 생각해 봅니다.