> From: Sean Whitton <[email protected]> > Cc: [email protected], [email protected], > [email protected] > Date: Thu, 25 Jun 2026 14:21:17 +0100 > > >> >> - 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. > > I think you mean: a decision not to have any more NN.x releases > excluding ones for critical fixes (mainly, security fixes).
Yes. > > 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. > > I think it's a bit worse than that: different people drift away from it > at different points. I would like us all to be singing from the same > hymn sheet on these matters. I'm okay with that, of course. The question is how to do that. > >> > 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. > > As the proposal here is a new workflow, I'm not sure what numbers you > could mean. Numbers to back the impression that "our NN.1 releases always feel like they take longer than we would like". Can you take the part of etc/HISTORY since Emacs 26.1 and tell what kind of schedule you'd like to see instead? > We could say that we stop doing this as soon as the next branch is cut. Sorry: stop doing what? > >> 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. > > My point is that we don't do that, in fact. We just fix stuff on > master. Otherwise any safe fixes should have been going to emacs-30 > right up until the emacs-31 branch cut. But they were not, they were > going to master. OK, then maybe we should be more vigilant, or maybe define some procedure for deciding whereto install bug fixes. In any case, if someone makes a mistake, it is easy enough to cherry-pick from master to the release branch, so such mistakes shouldn't get in the way of having more releases from the release branch than just NN.1 and NN.2. The main point, I think, is this: will keeping the release branch alive for longer delay the start of the release cycle for NN+1.1? It might do that for reasons of manpower and resources we have, if nothing else.
