Re: Emacs release cadence

[Eli Zaretskii <eliz@gnu.org>]

> Date: Mon, 28 Aug 2023 00:43:36 +0300
> Cc: luangruo@yahoo.com, philipk@posteo.net, danny@dfreeman.email,
>  stefankangas@gmail.com, emacs-devel@gnu.org, manuel.uberti@inventati.org
> From: Dmitry Gutov <dmitry@gutov.dev>
> 
> >> Releasing a new Emacs, say, even 6 month won't suddenly turn it into a
> >> crashing mess.
> > 
> > We already do it, or thereabouts.  Check out the last part of
> > etc/HISTORY.
> 
> What I meant are more frequent major releases, and some more patch 
> releases between them. And it looks like we're taking ~2 years between 
> major releases now.

Yes, but this started as a comparison with others, in which case the
difference between major and minor is not very relevant, since
Firefox, for example, doesn't have that distinction.

As for the frequency of major releases of Emacs, my experience so far
is that we cannot do much better without some drastic changes in the
procedures, which would probably require correspondingly drastic
changes in the core team and how it works.

> Anyway, specific intervals are not that important, it was just an 
> example: we could increase frequency, and nothing major would break.

IME, nope, we cannot, not by a lot, anyway.

> >> But we would get more and faster feedback for new features and
> >> changes.
> > 
> > Maybe, maybe not.  See below.
> 
> I'm pretty sure what I said is self-obvious: when instead of waiting for 
> somebody to check out our test builds we cut a release, a lot of people 
> will get it fairly soon, some later, but on the whole we'll get a lot 
> more feedback, much faster.

If we get feedback, but do not verify that the fixes indeed fixed the
problems, and didn't cause unintended problems elsewhere (something
that happens with alarming frequency around here), these frequent
releases become pointless.

> > Are you sure this will help?  Here's a typical case:
> > 
> >    https://lists.gnu.org/archive/html/help-gnu-emacs/2023-08/msg00454.html
> > 
> > This guy just recently upgraded to Emacs 29, and is reporting a
> > significant issue only now, a month after Emacs 29.1 was released.
> 
> As our (and others') experience shows, indeed, there is no way to ensure 
> that all bugs are fixed, all regressions are ironed out, and nobody is 
> ever unhappy.

Is this what you seriously think we are doing -- waiting for all the
bugs to be fixed?  It is not useful to discuss serious subjects such
as this one with such a non-serious attitude.

> Some people will wait longer before upgrading and ignore all pretests. I 
> only know, again, two things we could possibly do:
> 
> - Get releases out earlier (so the "one month since release" day comes 
> faster).
> - Get a lot more users and/or a lot more feedback from the same users.
> 
> The latter is a bet that even if, maybe, user C only uses Emacs 
> releases, there will be users D and E with similar enough workflows that 
> do test our snapshot builds and would report the same problems sooner.
> 
> Some problems will remain unreported anyway. Some stay that way for decades.

Are you talking from experience with releasing Emacs and collecting
the feedback?  Because I am, and I can tell that (a) we have no
control on how many users will return feedback, and (b) it takes
several weeks(!) to get useful feedback with real problems flowing
after a release.  This basically invalidates the simplistic model you
describe above.

> > I've seen similar things many times: people upgrade to a new Emacs
> > version months, and sometimes years, after that version was released.
> > Try to collect feedback for a release quickly given this upgrade
> > schedule.
> 
> People who stay silent about their problems will get what their pay for.

Problem is: most of them do.  People who want the latest ASAP simply
track the development branches, and we have their feedback more or
less in real time; more frequent releases will not improve the
feedback we get from them.

> But another upside of a shorter release cycle: even when encountering 
> late, embarrassing regressions, we would be able to say "it'll be fixed 
> in the next point-release" and people will know that they won't have to 
> wait long.

Not useful if people upgrade slowly and lazily.  Once again, those who
upgrade eagerly simply build from Git.