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

[Eli Zaretskii]

> From: João Távora <joaotavora@gmail.com>
> Date: Wed, 19 Apr 2023 14:04:10 +0100
> Cc: Dmitry Gutov <dmitry@gutov.dev>, rpluim@gmail.com, philipk@posteo.net, 
>       62720@debbugs.gnu.org, larsi@gnus.org, monnier@iro.umontreal.ca
> 
> Eli, do you want Eglot 1.14 (or 1.15, or 1.16 or whatever version
> is the latest Eglot release "several weeks" from now) to be in Emacs 29?

What I want in Emacs 29.1 (and any future release of Emacs) is the
latest version of Eglot that you, as Eglot developer, consider stable
enough to recommend to users of a stable Emacs.  Which version is that
is your decision.  But to make sense to me, the decision you make
should be consistent: if a version X.Y of Eglot is "stable enough" for
you to recommend that users of Emacs 29.n upgrade to it, then that
version X.Y can be part of Emacs 29.n.  (Of course, if you decided
that X.Y is stable enough _after_ Emacs 29.n was released, then X.Y
will be able to become part of Emacs only in Emacs 29.n+1 and later.)

I say above "to make sense to me", and I mean that, and only that.
That is, you _can_ decide that you don't agree with my definition of
consistency, and therefore Eglot X.Y will be recommended to users of
Emacs 29.n, but at the same time you don't want it to be in Emacs
29.n; such a decision will not "make sense to me", but we will still
act according to your decision in this matter.

I hope I clarified my position in this regard.

And before you draw too far-fetched conclusions from the above: I'm
saying this about Eglot, and only about Eglot.  Similar decisions
about other packages, and the conditions for including those other
packages in a stable Emacs versions, could very well be different.

> 1. Bundle Eglot 1.1x with Emacs 29 and all its up-to-date dependencies, so
> that, right at the moment of the Emacs 29 release, Eglot would function
> exactly the same on Emacs 28 + package-install.

That is probably not acceptable, although I'd need to know exactly
which versions of what other packages need to be imported into the
emacs-29 branch, to give a definitive answer.

> 2. Bundle a "Frankenglot" with Emacs 29 that has all the
> lisp/progmodes/eglot.el code of the future Eglot version, advertises
> itself as Eglot 1.1x, probably doesn't break, but does _not_ provide
> the same experience as Emacs 28 + package-install
> 
> Both options are bad, IMO, but 2 is worse.

I don't see why option 2 would be bad, let alone worse.  See below.

> The first reason that both options are bad is that you're discarding
> whatever value the pretest phase brings to the stability of Eglot's code.

Eglot itself isn't my problem.  My problem is the other packages that
upgrading Eglot, per option 1 above, will require to update: those
other packages usually affect much more than just Eglot, and therefore
bringing their potentially less stable code into emacs-29 might break
much more than just Eglot.

> Eglot, being a part of Emacs the Emacs code base, benefits from the same
> testing all its code does.  You're discarding that value, and I think
> it's bad, because the pretest is supposedly there for a good reason. A bug in
> Eglot 1.1x will just escape us and there's no time to fix it.

Please leave this consideration to me, it is exactly the kind of
judgment call I make every several days when someone asks whether a
particular change is OK for the release branch.  And in the case of
Eglot I already said that IMO we should include in Emacs 29.1 the
latest stable version of Eglot, thus my decision about that was
already made in favor of upgrading Eglot on emacs-29.  But I won't
insist if you are uncomfortable with that.

> The second reason only applies to option 2. It would completely confuse
> users.  A user running Emacs 28 would see a much better 1.1x than
> the 1.1x bundled in Emacs 29.

No, users of Emacs 28 who installed the latest stable Eglot from ELPA
should see almost the same version of Eglot as users of Emacs 29.1 if
that will come with the same stable Eglot.  Unless you intend to
somehow degenerate important parts of Eglot in what you call
"Frankenglot", whatever that means.

My interpretation of option 2 is that we get a newer Eglot (1.14 or
1.15, whichever you decide is stable enough) with various minor
fallbacks intended to work around the fact that dependency packages
are not necessarily at their versions for which Eglot 1.14/1.15 was
designed to work, if the versions of those dependencies in Emacs 29.1
are older.  That is, 1.14/1.15 without the mandatory requirement o
upgrade any other package already in Emacs.  If that is not what you
mean, then perhaps consider this as option 3, which is the one that
makes the most sense to me, and if possible and agreed upon, will be
accepted into emacs-29.