我同意其他人的说法，我喜欢拟议变更的方向。而且我认为提议的分支名称比旧的更直观 
对我来说还不清楚的是 release 和 esr 分支的升级过程将如何进行（latest 似乎很简单）。您提到，在任何时间点，当前版本（我们称之为 n）和前一个版本（n-1）都将得到支持，并且作为管理员，我将可以选择何时升级。
根据我使用其他软件的经验，当新版本（n+1）到达时，我会收到版本 n+1 可用性的通知。然后，我可以选择进行主要升级（相当于 Linux 上的 apt dist-upgrade）或进行次要/标准更新（相当于 Linux 上的 apt upgrade）并停留在版本 n。这是否会被纳入 Discourse 启动器脚本？
另外，我理解您希望尽量减少发布仪式/流程，但我的直觉是，正常版本和 esr 版本在发布前至少会经过一些额外的测试。这可能是我长期从事企业 IT 工作造成的 
最后，我想知道每月发布是否真的“太快了”。这当然也是主观的，但根据我作为志愿者管理 IT 方面的经验，我可能没有时间每月进行较大的更新。基于此，我想知道您是否可以通过简单地每季度发布一次，并且不设单独的 esr 分支，只设 release 分支，来让您作为 Discourse 开发者的生活更轻松一些。