> From: Sean Whitton <[email protected]> > Cc: [email protected], [email protected] > Date: Wed, 24 Jun 2026 11:55:30 +0100 > > Our practice has been that for a while after a NN.1 release we install > bug fixes on the emacs-NN branch, and keep merging it to master, but > then as time passes we drift towards only installing things on master, > returning to the emacs-NN only if there is a critical bug fix for which > we immediately want to do a point release. > > I would like us to be more deliberate about how we use the emacs-31 > branch after the release of Emacs 31.1, using it in a more principled > way. I've CC'd two of our downstreams for feedback. > > Here are some ways we could go: > > - Decide that only critical bug fixes go on the emacs-31 branch. > Stop putting other bug fixes there are soon as Emacs 31.1 is out. > "Critical" means we want to do a point release as soon as the fix is > installed.
IOW, if there are no critical bugs, we never release Emacs 31.1, but go directly to starting the Emacs 32 release cycle? > - Continue to install fixes on the emacs-31 branch as though we were > still in the later stages of the pre-release freeze. That's what we've been doing until now on every release branch after the NN.1 version was released. > - A halfway house: the second option until the release of Emacs 32.2, You mean 31.2? > which we will expect to do within a few months, and thereafter the > first option, with only critical bug fixes permitted. Theoretically, we've intended to do it this way, but actually ended up doing the previous one. > The advantage of the second two options is that our users would get > fixes for various bugs much -- years -- sooner than they otherwise > would. That's a service that it would be nice to provide, if we could. Not sure I understand why. Presumably, you mean we should install on the release branch fixes that are not-so-safe, instead of installing them on master? If so, we tried that before Emacs 26 (I think), and the results were unsatisfactory: the fixes would destabilize the release branch and bring new bugs. Which is why we switched to the current MO. Or did I misunderstand what you meant here? > The costs would be: > - for everyone: having to wait for one of the head maintainers to okay > installing something on emacs-31 instead of just going ahead and > installing it on master > - for the head maintainers: having to make those decisions regularly for > a longer period than just during our feature freezes > - for the head maintainers: cutting more pretests and point releases > than at present. > > Have I missed anything here? > > I think that the cost of cutting more pretests and point releases is > acceptable. I'm happy to do it and I want to script more of the process > than is currently automatic at present, anyway. > > The other two costs I'm not sure about. I think the main cost, one you haven't mentioned, will be to delay the NN+1.1 release (because more important changes are being installed on the release branch, and more energy is directed towards emacs-NN branch releases). Also, our experience is that as time passes, it becomes harder and harder to keep releasing from emacs-NN without adding new features, because the world at large doesn't stand still. For example, when Unicode releases a new version of the standard, is it reasonable to put out emacs-NN.x releases that support only the previous version of Unicode? IOW, once the release branch is open to anything but strictly safe bugfixes, and it lives for a long time, it becomes harder to keep it stable.
