> Date: Fri, 26 Jun 2026 09:29:25 -0700 > Cc: [email protected] > From: Jim Porter <[email protected]> > > On 6/26/2026 8:28 AM, Sean Whitton wrote: > > Stefan Monnier via "Emacs development discussions." [25/Jun 11:13pm -04] > > wrote: > >> - After NN.1 is released, I expect much fewer people run the `emacs-NN` > >> branch, so any regression risks remaining undetected before the next > >> (minor) release. If the regression is detected earlier, it'll likely > >> be detected by someone running `master` and there's a chance that the > >> fix will make it only to `master` if we don't notice the link to the > >> previous bug-fix or don't notice that that previous bug-fix was > >> installed in `emacs-NN`. > > > > Thanks. I find this to be a persuasive reason not to try to make more > > point releases. > > > > I'll work on a patch to our notes in admin/ for the middle ground policy > > where we always expect to make a .2 that has lots of fixes (and so > > people should continue installing fixes there instead of master until > > the release of .2), but thereafter it's critical bug fixes only. > > I think some of this aligns thanks to timing. Recently, major Emacs > releases have taken roughly 1-1.5 years since the last major release, > and minor (.2) releases have taken roughly 6 months since the previous > (.1) release. By the time maintainers would otherwise be prepping a .3 > release, we'd be close to creating a new release branch for the next > release.
That's a wrong conclusion, at least IME. The release cycle for NN+1 major release will only start once we decide that there are no longer important problems in emacs-NN to justify another NN.x release. As long as that decision is not made, the next release cycle will not start. So you are making conclusions from the fact that, for almost all Emacs versions since Emacs 26 till now, we decided another NN.x release after NN.2 was not justified, and _then_ started the release cycle for NN+1. IOW, the cause and effect are the other way around.
