Re: Stability of core packages (was: Not easy at all to upgrade :core packages like Eglot)

[Dmitry Gutov <dmitry@gutov.dev>]

On 20/04/2023 12:47, Eli Zaretskii wrote:

>>> Also, does package.el support "downgrading" to the bundled version?
>>> Did anyone actually try that?  In particular, what happens with the
>>> dependencies the user upgraded together with the package being
>>> "uninstalled", due to the minimum requirements of that package?
>>
>> It should work by "uninstalling" the package. An when you uninstall a
>> package, package.el warns you about any dependencies that would be
>> broken this way. Someone should test it just in case, of course.
>>
>> But the important part is that the bundled package stays installed. You
>> asked why we can encourage people to upgrade said packages freely. One
>> answer is that they have a safety net.
> 
> All those differences disappear when we are discussing core packages.
> Which is my only focus in this discussion.

Disappear, why? The core packages are the only kind of "bundled" 
packages we have (for now), and so they are the only ones that can be 
safely reverted to the bundled version via uninstallation.

>>>> We have elpa and elpa-devel. The latter is "explicitly unstable" and the
>>>> former is "checkpoint releases".
>>>
>>> So what is the stability measure of "elpa", again?  Is it on par with
>>> the Emacs's release branch?  Could it be?
>>
>> It's more stable than 'git clone' but less stable than using a release.
>>
>> And this will stay that way while we're using it to help stabilize
>> package versions, too.
> 
> I very much hope it doesn't stay that way for core packages.

Let me try again: one of the uses of ELPA is to push out the package 
release "into the real world" so that more people can test it.

So that "N weeks later" we can consider is "stable" and be content to 
have it in an Emacs release.

By the very definition, the same release wasn't "stable" N weeks ago, 
just as it was published. So ELPA cannot be considered to have the same 
level of stability because we also use it for testing this way (among 
other things).

>>   > If not, why not?
>>
>> I don't think we want ELPA to have the same frequency of package
>> releases as Emacs itself.
> 
> This is a red herring.  Emacs releases are less frequent because Emacs
> is a large collection of packages, and thus the period required for
> its stabilization is much longer.  A single core package can apply
> stability criteria and still not go anywhere near the Emacs release
> frequency.  It does need more effort on the part of the package
> developers, but the effect on the release frequency will be minor.

I guess you're right.

But note that as per above, if we wanted ELPA to be the "stable" source, 
we'd need some other testing ground before pushing releases to it. E.g. 
we could just wait for people using the master branch to report 
problems. But since there are fewer of them than there are ELPA users, 
it stands to reason that the stabilization periods must become longer. 
Maybe not two years, but longer than with ELPA.

>>> Users who must have these features (presumably because they must use
>>> servers which require that) will have to give up some stability
>>> expectations.  Exactly like users who must have some new enough
>>> feature of Emacs which is only available on the master branch.
>>>
>>> So once again: what is fundamentally different or new about packages
>>> which develop at fast pace, in the context of this discussion?  Why do
>>> we need to bring up those details here?
>>
>> It's an issue of whether a "stable" Eglot could actually be useful 2
>> years later for most people.
> 
> "Two years" because you think the release frequency of Eglot will be
> slowed down to such abysmally low value?  As explained above, I think
> this is not going to happen, so there's no need to assume this will be
> the outcome.

No, no. I'm talking the scenario with users who are going to stay with 
the version of Eglot that comes with Emacs 29, for two years without 
upgrading. That might not be wise in a lot of cases (admittedly, this is 
just a guess at this point, looking at the speed of changes around the 
community), so we should make it easy to upgrade.

I don't believe the upgrade must be made automatic, however.