Re: The emacs-31 branch during the next release cycle
Jim Porter <[email protected]> Fri, 26 Jun 2026 09:29:25 -0700
| Newsgroups | gmane.emacs.devel,gmane.linux.debian.devel.emacsen |
|---|---|
| Message-ID | <[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. Since multiple factors point towards this release strategy, it seems like a good one to settle on. Writing down these guidelines in admin/ makes sense to me.