Emacs release cadence

[Dmitry Gutov <dmitry@gutov.dev>]

On 27/08/2023 16:28, Eli Zaretskii wrote:
>> Date: Sun, 27 Aug 2023 16:12:00 +0300
>> Cc: Eli Zaretskii <eliz@gnu.org>, philipk@posteo.net, danny@dfreeman.email,
>>   stefankangas@gmail.com, emacs-devel@gnu.org, manuel.uberti@inventati.org
>> From: Dmitry Gutov <dmitry@gutov.dev>
>>
>> On 27/08/2023 15:57, Po Lu wrote:
>>> Dmitry Gutov<dmitry@gutov.dev>  writes:
>>>
>>>> We could easily have more frequent releases, it's all in the hands of
>>>> the maintainers, actually. Stability/velocity tradeoffs.
>>> Producing another atrocity following the footsteps of Mozilla?  No
>>> thanks!
>>
>> 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.

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

>> 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.

>> That's the main issue why we have to drag on the release schedule: we
>> don't get reports of regressions soon enough after introducing them. So
>> we have to wait months for the users to try and report back.
>>
>> How to change that? Either make releases more often, or make snapshot
>> releases more prominent and easier to try, or improve the bug reporting
>> experience so that more people do that. Or all of that together, of course.
> 
> 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.

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.

> 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.

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.

>> I wonder what wonderful curious bug reports we would also get if we had
>> the number of users that Firefox has.
> 
> If we never do anything, we will keep wondering, and it will remain
> forever in the "he said, she said" department.

Indeed.