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

[Eli Zaretskii]

> Date: Tue, 18 Apr 2023 12:36:12 -0700
> Cc: dmitry@gutov.dev, joaotavora@gmail.com, emacs-devel@gnu.org
> From: Jim Porter <jporterbugs@gmail.com>
> 
> >> * Stable: the version of a package included in the latest Emacs tarball
> >> * Latest: the latest version on GNU ELPA (etc)
> >> * Devel: the latest version on GNU-devel ELPA (etc)
> > 
> > I think we need only two.  Stable can move to the next version, since
> > packages are released more frequently than Emacs.
> 
> At least from a user POV, I think it makes sense to distinguish among 
> all three of these. For example, I might use the version of Eglot in 
> Emacs 29, or I might install it from GNU ELPA, or I could even install 
> it from GNU-devel ELPA. I might even switch back and forth depending on 
> what my needs are (and in fact, that's exactly what I do with Eglot; 
> while I usually prefer to stick on the GNU ELPA version, sometimes I 
> switch to GNU-devel ELPA if there's a fix for a bug I find very bothersome).

>From a user POV, what is the qualitative difference between "Latest"
and "Stable"?  As soon as some newer version on ELPA becomes stable
enough, why should the user assign any significance to the previous
version included in the last released Emacs tarball?  Please keep in
mind that the version you call "Stable" is just one that was ready in
time for the last Emacs release, and is otherwise no different from
what you call "Latest".  IOW, assuming that versions in Emacs and on
ELPA are declared "Stable" using the same criteria and the same
procedures, they are not really different from the stability POV.
Moreover, the version in Emacs could (hopefully, very infrequently)
have some bug that went unnoticed during the pretest, and that bug
could now be fixed in the ELPA version.

Unless, that is, you somehow trust the decision-making process for an
Emacs release much more than you trust the same process for ELPA
releases.  But in my book, those should be the same processes,
especially if we ever get to the situation where such packages are not
in emacs.git anymore.

> I think this set of three levels also makes it easier - at least for me 
> - to reason about what to do with something like ElDoc. If a user 
> installs Eglot from GNU ELPA (i.e. the user gets "Eglot latest"), should 
> it automatically install ElDoc from GNU ELPA ("ElDoc latest") or should 
> it use the ElDoc from the Emacs tarball ("ElDoc stable")?

My answer is NO, but that is a separate issue.

> If there were only two levels - latest and devel - then I think the 
> answer to the Eglot/ElDoc problem would simply be: installing Eglot 
> latest should pull in ElDoc latest.

By default, perhaps.  But the user should still be able to say not to
upgrade any dependencies unless they _must_ be upgrade, i.e. the
package the user wants to upgrade _requires_ a newer version of
another package.

And again: this is a separate issue.

> Since there's no higher "stability 
> gradation" than latest, we wouldn't really be able to say that 
> ElDoc-from-Emacs is better/stabler than ElDoc-from-ELPA. (Well, we can 
> still *say* that, but I think it helps to embed our reasoning for it 
> into these stability gradations.)

It isn't our decision, it is up to the user.  _We_ could recommend to
upgrade to the latest version (if we will indeed get to the position
where we can do that in good faith), but the user could decide he/she
doesn't believe us, and doesn't want any additional risks.

> > How is this different from what we have in Emacs?  An exciting new
> > feature is sometimes deferred to the next major release if the release
> > branch is close enough to a release.  There's nothing new here, just
> > the fact that sometimes useful new features could destabilize Emacs,
> > so one needs to choose which one it wants more.
> 
> I think the main difference is that Eglot and Emacs (and ElDoc, for that 
> matter) all have different release cadences

But this difference, if it is real, should really disappear, right?
the periods of time when an Emacs release branch is closed to unsafe
changes is nowadays relatively short, so there should be no problem
for the core package to adhere to the same basic routine, i.e. keep
the next "candidate for latest" closed to risky changes for a couple
of months, before it actually becomes "latest".  And then the
difference will all but disappear.

> With Emacs itself, we can ensure that every package that ships in
> the tarball is works well with each other; when we distribute a
> package on ELPA, this gets trickier.

This "trickier" part will need to be fully resolved as part of getting
our act together for the brave new world where core packages are
maintained only on ELPA.  So we might as well start now, because I see
no reason why this difference should even exist -- it's not like we do
in Emacs something too complicated and expensive.

Btw, does package.el even allow to "downgrade" back to the version
that came with Emacs?