bug#62720: 29.0.60; Not easy at all to upgrade :core packages like Eglot

["João Távora" <joaotavora@gmail.com>]

On Wed, Apr 19, 2023 at 6:59 PM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: João Távora <joaotavora@gmail.com>
> > Date: Wed, 19 Apr 2023 18:27:08 +0100
> > Cc: dmitry@gutov.dev, rpluim@gmail.com, philipk@posteo.net,
> >       62720@debbugs.gnu.org, larsi@gnus.org, monnier@iro.umontreal.ca
> >
> > On Wed, Apr 19, 2023 at 5:50 PM Eli Zaretskii <eliz@gnu.org> wrote:
> >
> > > > This just doesn't make any sense to me.  Can't you understand that other
> > > > maintainers also value stability for their packages?
> > >
> > > Of course I can.  But once again: if Eglot 1.14 is not stable enough,
> >
> > Stable enough for whom, or for what?  Stability is quantity in a spectrum.
>
> Stable for us.  We are not talking about absolutes here, we are
> talking about relative stability.  I'm saying that if some package is
> stable enough to be used with Emacs version X.Y, it is by definition
> also stable enough to be included in Emacs version X.Y.  The relative
> stability levels of these two cases must be the same, or else we are
> inconsistent in our own judgment of stability.
>
> > I think Emacs releases should come with the most well tested code.  No
> > program is perfect.  Eglot 1.14 is stable, but it's not _as_ stable as Eglot
> > 1.12 because the latter has seen more testing?
>
> Then how come we tell users of this same Emacs 29 to update to Eglot
> 1.14 without too much thought?  And you even insist on making that
> automatic when packages are updated at startup.  Won't that
> destabilize their Emacs?

I don't dictate to users how much to think :-)  I just assume that
they've been thinking about it in Emacs 28, and they are happy
with this amount of thinking, else they would be complaining
about stability, and they aren't.  Maybe some users are holding
on to Emacs 26.3 + Eglot 1.0 for dear life, who knows? It's very
simple to me.

To summarize and to hopefully answer the question that you repeatedly
put before me, this is my recommendation to users:

 "Dear user,

  Emacs 29 will come with the most stable version I can offer, and I
  can tell you, prospective user, that it has been through as much
  of the Emacs 29 pretest period as possible. If you, prospective user,
  are interested in the features listed in etc/EGLOT-NEWS, you may try
  upgrading to the latest version (I hope it will be easy, good luck!)
  In the unlikely event that things go sour for your particular
  LSP server and use case, you have my deepest apologies, and you
  should revert back to the version bundled with Emacs 29.

  Thank you,
  Your maintainer"

The second part of this recommendation is what I've always recommended.
I've never had to phrase it like this, but this has always been my
recommendation.

> No, I suggest that you make changes on master so that these problems
> are avoided in the first place.  Changes in a core package on the
> Emacs master branch should be done while keeping in mind that this
> same version of a package will be on ELPA and users of older Emacsen
> will install that newer version.  So the newer version on master
> should avoid making changes which would mandate newer versions of
> other packages, by providing the necessary compatibility fallbacks.

So, if I want to do a feature on master that depends on some
new infrastructure on package X that appeared on master (say Xref's
upcoming support for "find any type of thing declaration/macro/etc"),
I have to do no less than duplicate that new infrastructure in Eglot.el
and do a runtime check.  That's... not good, to say the least.

But noted.  Now I (think I) understand what you suggest.

AFAICT basically suggesting all Package-Requires are eliminated,
to get rid of package.el dependency system.  You should argue for
that in emacs-devel explicitly so, I think, because that will
probably elicit some interesting reactions from :core package
developers. "Package-Requires" is used liberally now AFAIK

It's the most basic underpinning of Eglot's design philosophy,
if there such a thing.  That's why Eglot is called "minimal".  It's
not minimal in functionality!  It's minimal in size and complexity
because it reuses code and keeps itself simple.  And if I may be a bit less
humble about it, I've gotten a few compliments about it.

João