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.