> From: Sean Whitton <[email protected]> > Cc: [email protected], [email protected], > [email protected] > Date: Thu, 25 Jun 2026 11:31:09 +0100 > > Eli Zaretskii [24/Jun 6:10pm +03] wrote: > >> 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? > > Emacs 31.2* as you followed up, but yes.
Our experience is that NN.1 always has regressions, so NN.2 is usually needed to have a stable, relatively bug-free NN.x release. A release cycle of a major version takes at least 6 to 9 months, whereas a NN.2 release can be done sooner. So if we immediately start the release cycle of the next major release, users will wait longer to have minor bugs fixed. Moreover, NN.x versions will never become more stable than they were at initial release, which for a feature-rich release usually mean not stable enough. By contrast, with the current practice we can tell users to upgrade when NN.2 or NN.3 is released, and they then have more stable Emacs with fewer regressions. > >> - 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. > > It isn't though, and that's my point. We do that for a while and then > gradually do it less and less, with no rhyme or reason for the process. We basically stop updating the release branch when we are about to feature-freeze the master branch in preparation for the next release cycle. Or at least that's the intent; I know that the practice is somewhat different (and with Emacs 31 we delayed the release cycle too much, but there were reasons for that). The trigger to stopping the updates of the release branch is actually a decision not to have any more NN.x releases. That decision is not always explicit, but at least for me, it was always the the trigger. You can see that by watching the branch on which I fix the documentation. > >> 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? > > No, I only meant safe fixes -- but then users would get those safe fixes > years sooner than otherwise. Lots of our fixes are safe. "Years" should be an exaggeration. Look at etc/HISTORY and I think you will see that in many/most cases it only took months, not years, between the last NN.x and the first NN+1.1. > > 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). > > I agree that this would be a cost, but it doesn't seem to me like it > would be the main cost. Our NN.1 releases always feel like they take > longer than we would like, and I don't think this would add a lot. Can you back up this with numbers, taken from etc/HISTORY? Because I think your impression is wrong. NN.1 release takes longer because it's a feature release: there are usually quite a few new features, and it takes time to polish them during the pretest. If you have ideas for how to shorten that period, please tell. The problem with Emacs (as compared to most other programs) is that it is enormously large, has a lot of independent parts that cannot be tested unless they are actively used by someone, and it touches a lot of very different domains. It takes time to test all that enough so we can be sure the release will not be horribly broken for someone, because their particular packages or domains were never used enough after the changes on master. > > 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. > > I think it should still only be strictly safe bug fixes, the difference > is that we include strictly safe bug fixes for bugs that are of less > critical severity -- how bad the bug is for users and how safely it can > be fixed vary indepedently. I think we already do that, or at least we intend to. I suggest to look at the emacs-31 release branch as a test case and see where we can do better.
