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

[Dmitry Gutov <dmitry@gutov.dev>]

On 18/04/2023 15:57, Eli Zaretskii wrote:

>>>> On 14/04/2023 22:28, Eli Zaretskii wrote:
>>>>> If, OTOH,
>>>>> you think that it's imperative to allow_all_  users of Eglot with
>>>>> Emacs 29 to upgrade to Eglot 1.14 (and 1.15, 1.16, etc., when those
>>>>> become available), then we should release Emacs 29 with 1.14.
>>>>
>>>> Was this question about stability only?
>>>
>>> It was about the criteria for which versions of core packages to ship
>>> with a release.
>>
>> I don't think we can get a single set of criteria across core packages.
> 
> We don't need to have just one set.  Packages are different in both
> their complexity, their dependence on other packages, and dependence
> of other packages on them.  So one set is unlikely to fit the bill,
> indeed.
> 
> But that doesn't mean we shouldn't have criteria at all.  We should
> strive to have a small number of them, and we should know which set is
> applicable to which class of packages.

It's a good question, but not a deciding one WRT what we should do with 
Eglot for Emacs 29, I think. I hope I'll be able to explain that below.

> This will be one of the serious issues if we ever move to having some
> packages only in elpa.git, and will then bundle them when preparing an
> Emacs release tarball.  It will be imperative to know at that time
> which version/branch of each such package to take as part of preparing
> a release.  We must have a solution by then, so this is as good time
> as any to start discussing the issue.

Sure. Please keep in mind, however, that very few of external packages 
have separate branches for releases and development. I guess Org does, 
but I'm not sure if others exist. One of the reasons for that is that 
the ELPA repositories only package the very latest released version 
anyway and quickly delete the older ones. And package.el is the foremost 
distribution method for Elisp code.

For :core package, we also have Emacs's own development and release 
branches. But only master branch has versioned releases cut from it. 
It's hard to say whether the time the code has spent in a given 
'emacs-xy' branch brings maturity to it, and how much.

So every time a new version if tagged, it's a value judgment on the part 
of the maintainer: whether enough time has passed since the most recent 
big feature was added, whether there were bug reports or not.

The MELPA project has helped a lot with this over the years because it 
popularized snapshot versions. So when a package is feature on MELPA, 
the author could be fairly sure that a lot of users have downloaded the 
latest snapshot and gave it a try, and the lack of new reports means 
it's probably okay. MELPA has the problem that the "Stable" repository 
is not very popular, though. We here have it in the reverse: I'm not 
sure how many people make use of elpa-devel (GNU-devel ELPA). Probably 
not many.

>> E.g. Org is developed externally, has its own community of significant
>> size, and does split off release branches (with additional testing, I',m
>> guessing).
>>
>> Eglot, OTOH, is developed only here, with no additional release workflow
>> other than what MELPA/GNU ELPA historically provided: collect up some
>> features/fixes, bump the Version header, and push a new release out to
>> the users. The lack of extended testing period is made up for with the
>> capability to push out a new fixed version overnight. That's why the
>> difficulty in upgrading to the latest version (for Emacs 29 users) is
>> going to hurt.
> 
> If some core package is not tested enough before it gets a new
> version, then why are we okay with telling users of a stable Emacs to
> update the package willy-nilly as soon as another version is on ELPA?
> Shouldn't we at least warn them, or, better, somehow indicate that
> this version is not yet considered stable?

I have a different answer from all that had been presented here: because 
the user can uninstall it.

Uninstall any newer installed version and stay with that one that had 
been bundled with the Emacs release. As long as *that* one has been 
picked well enough to be stable, and can be reverted to, we can afford 
not to worry too much about the user installing another version.

It's like reverting to a more stable distribution channel, to use the 
analogy from the bug discussion.

> IOW, shouldn't packages have some "stability gradation" that is
> visible when users look at the list of packages via package.el?
> Shouldn't we allow users to tell package.el which stability they want
> to download, so that unstable packages don't inadvertently get
> installed and mess up their production environment?

We have elpa and elpa-devel. The latter is "explicitly unstable" and the 
former is "checkpoint releases".

Neither keeps the previous versions around, so it's not like the user at 
any point could make a choice to install a minor version update instead 
of going up a full major version. The only choice is to update to the 
latest, or not (by using elpa-devel, though, the user might opt into 
having "the latest" mean "the latest commit in master").

>> BTW, if you recall the threads before Eglot was added, I was against
>> that, and one of the things I cited is an LSP client has inherently high
>> development velocity. Maybe the LSP community will settle/mature/stop
>> adding features one day, but it's not there yet.
> 
> I don't see what development pace has to do with this issue.  If a
> package is being developed at a high pace, it might mean that the
> stable version will lag more.  But what does this change in principle?

It matters when we're talking not about simple additional, optional 
features, but about changes that keep pace with the evolution of the LSP 
standard, with new LSP servers that arrive, new changes in existing 
protocols. Things that users come to expect to be able to use now, and 
not in 3 years.

Taking a conservative stance can work when the ecosystem supports it 
too. E.g. if every LSP server that we support now had an implicit 
promise to be properly maintained for 3 years since, at least. I don't 
think that's the case. Almost every one could be deprecated in that time 
frame, with community being recommended to switch to a newer one.

>>>> Because since we've decided in favor of stability of package.el, and
>>>> against eglot's easy upgradability, I would suggest to backport Eglot
>>>> 1.14 to emacs-29.
>>>
>>> I won't object.  In fact, I asked up front why not.
>>
>> Note that that suggestion comes with a fix to eldoc which you so far
>> have rejected for emacs-29.
> 
> You mean, the change in ElDoc that avoids the "jumping mode line"
> issue?  If so, it is unfortunate for Eglot to depend on that, because
> it means users of Emacs 29 will be unable to upgrade to Eglot 1.15
> without by side effect installing a newer and potentially less stable
> ElDoc.  (I also am surprised that change is a must for Eglot 1.15.)

Sorry if that was unclear: yes, the fix for "jumping mode-line and 
blinking text", but not as a bump in dependency. Just to backport the 
fix to eldoc.el inside emacs-29.

But Joao has explained that that idea is impractical because Eglot 1.14 
depends on Eldoc 1.14.0. And I just wanted a particular fix from it. So 
backporting the thing I wanted from Eglot 1.14 (taking up much less 
space in the echo area) is not really feasible because it depends on a 
fairly recent addition to eldoc.

To clarify: I made that suggestion from the premise that we do expect 
and encourage a fair fraction of the users to use just the versions of 
Eglot and Eldoc that come with Emacs 29, and never upgrade to the latest 
ones.

> So this again goes back to the main issue: how should the stability
> considerations affect development of core packages and their
> "stability gradation"?  Developers of core packages should keep these
> aspects in mind at all times, and, for example, avoid dependencies on
> other packages that aren't absolutely necessary.

I agree with that stance, in general.

And as per above explanation, Eglot 0.14 depends on Eldoc 0.14.0 not 
because it's the very latest and spiffiest version, but because it needs 
a particular feature from it.