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

[Eli Zaretskii <eliz@gnu.org>]

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

> > > It's certainly NOT about "not wanting to invest the effort".  That effort
> > > would amount to forking Eglot in its feature set so that effort would be
> > > a disservice to everybody.
> >
> > No, it doesn't require any forks.  It requires more cautious
> > introduction of new features into Eglot on master.  And yes, it's
> > extra effort.  But IMNSHO, users will benefit, so in my book it's
> > worth it.
> 
> AFAICT you suggest a different eglot.el in Emacs 29 which has the
> same features as eglot.el in Emacs master, but without needing
> the dependencies that the master version can enjoy.  That's a
> fork if I've ever seen one.

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.