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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Wed, 19 Apr 2023 22:25:08 +0300
> Cc: joaotavora@gmail.com, emacs-devel@gnu.org
> From: Dmitry Gutov <dmitry@gutov.dev>
> 
> >> 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.

All those differences disappear when we are discussing core packages.
Which is my only focus in this discussion.

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

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

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