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

[Jim Porter]

On 4/18/2023 12:21 PM, Eli Zaretskii wrote:
> > Date: Tue, 18 Apr 2023 11:56:58 -0700
> > Cc: joaotavora@gmail.com, emacs-devel@gnu.org
> > From: Jim Porter <jporterbugs@gmail.com>
> >
> > It sounds to me like there are 3 or 4 levels (depending on how you count):
> >
> > * 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).

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")?

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

> 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, so it would be helpful to 
have some functionality to help us manage that. 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.

> > One alternative would be for packages to be able to *recommend*
> > dependencies. Then, Eglot could recommend newer versions of ElDoc, but
> > they wouldn't actually be required.
>
> This is probably needed, but it requires non-trivial support from
> package.el, to let informed users select the updates that fit their
> stability requirements and feature needs.

Yeah, that's where this gets tricky for Emacs 29: it's probably a bit 
late to add major new features like this to package.el for 29. However, 
we might be able to accept an imperfect solution for Eglot today while 
working to provide a better way for Emacs 30.