Eli Zaretskii [25/Jun 2:19pm +03] wrote: > 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.
Okay, let's rule out that first option, then. >> >> - 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). > 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. > "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. Fair. >> > 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. We could say that we stop doing this as soon as the next branch is cut. > 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. 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. -- Sean Whitton
