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

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: João Távora <joaotavora <at> gmail.com>
Cc: 62720 <at> debbugs.gnu.org, rpluim <at> gmail.com, philipk <at> posteo.net, dmitry <at> gutov.dev, monnier <at> iro.umontreal.ca, larsi <at> gnus.org
Subject: bug#62720: 29.0.60; Not easy at all to upgrade :core packages like Eglot
Date: Wed, 19 Apr 2023 21:00:02 +0300

> From: João Távora <joaotavora <at> gmail.com>
> Date: Wed, 19 Apr 2023 18:27:08 +0100
> Cc: dmitry <at> gutov.dev, rpluim <at> gmail.com, philipk <at> posteo.net, 
> 	62720 <at> debbugs.gnu.org, larsi <at> gnus.org, monnier <at> iro.umontreal.ca
> 
> On Wed, Apr 19, 2023 at 5:50 PM Eli Zaretskii <eliz <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.