emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Stability of core packages (was: Not easy at all to upgrade :core pa


From: Dmitry Gutov
Subject: Re: Stability of core packages (was: Not easy at all to upgrade :core packages like Eglot)
Date: Wed, 19 Apr 2023 22:25:08 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0

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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]