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

[Dmitry Gutov <dmitry@gutov.dev>]

On 19/04/2023 15:47, Eli Zaretskii wrote:

>>> 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.
> 
> Then maybe ELPA will have to change as well.

I don't think that should be, or can be reasonably required. But that 
can be put it to a separate discussion. With Stefan and Philip involved, 
probably.

>> 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.
> 
> Similar judgment calls are necessary for Emacs.  So I see nothing here
> that brings some fundamentally new issues.
> 
> Moreover, I don't see how this affects the need to have good criteria
> for stability, and the importance of applying those criteria when
> deciding which versions to bundle with Emacs.

Ok, if the question is just "how to choose the version of :core package 
to bundle with an Emacs release", then just see the criterion "N weeks 
have passed without issue" that I just described in the bug thread.

This one doesn't need any changes to ELPA, and I've been using it, more 
or less, for some years now.

>>> 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.
> 
> User can also downgrade to a previous version of the package, don't
> they?  Or if they cannot, they should be able to do that.

Even if there was such possibility, they wouldn't have a single stable 
version to go back to (they'd have to make a choice). When we bundle a 
version, that's one fewer question to answer.

> Once that
> is possible, what exactly is the difference between these two kinds of
> packages?  Downgrading to an older version when a newer one is buggy
> or otherwise unsatisfactory should be supported for all packages.

Then the difference would be that we hand-picked a set of particular 
versions of packages, whereas for third-party packages that was done (or 
failed to be done) by other people we have no responsibility over.

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

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

 > If not, why not?

I don't think we want ELPA to have the same frequency of package 
releases as Emacs itself.

We could add a new archive, though. Like elpa-very-stable. Which would 
be pushed, for example, the same versions of bundled packages that go 
into Emacs releases. Or something like that.

>> 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.
> 
> That in itself is a serious deficiency, IMO, and we should fix it by
> providing the "downgrade" option.

Doing that for every package will mean more work for everybody around, 
and it'll also increase the costs of hosting packages considerably.

>>> 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.
> 
> 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. If not (I admit I don't know for certain), 
we should choose to focus on other scenarios and needs, and less on 
stability in this particular case.

>> 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.
> 
> How does this help us move forward with the discussion and with
> handling this issue?  Conservative doesn't mean stupid; if some
> external factor changes outside of our control and forces us to make
> potentially destabilizing changes, what else can we do that requires a
> discussion?

No, I don't think that conservative means stupid. I am fairly 
conservative in some things, just not in others.

Or take Joao: he's at the moment being conservative about how the users 
install Eglot and have had it upgraded over time when using all previous 
releases of Emacs.

> And how does it impact what we should do about
> categorizing package releases according to their stability and about
> the decisions which version to bundle with Emacs?

No, that's a different question. One I had hopefully addressed above.

>> 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.
> 
> AFAIU, João is of the opposite opinion: he thinks that most Eglot
> users will want the latest version on ELPA, or at least a version that
> is newer than the one bundled with Emacs.

I am of the above opposite opinion as well, but I can appreciate your 
POV as well, I think. And, well, if the ultimate decision is made using 
the latter principle, we still could make the most of it.

>> 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.
> 
> And there's no reasonable way of adding to Eglot 1.14 some fallback or
> compatibility shim to remove that dependency?

Everything's possible. It might not even be too hard.

But if we're talking about the improvement I was eyeing (better 
eglot<->eldoc behavior all around), then a simple shim won't cut it.