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

[Dmitry Gutov]

On 17/04/2023 05:24, Eli Zaretskii wrote:
> > Date: Sun, 16 Apr 2023 23:46:37 +0300
> > Cc: rpluim@gmail.com, philipk@posteo.net, 62720@debbugs.gnu.org,
> >   larsi@gnus.org, monnier@iro.umontreal.ca
> > From: Dmitry Gutov <dmitry@gutov.dev>
> >
> > On 14/04/2023 22:28, Eli Zaretskii wrote:
> > > If, OTOH,
> > > you think that it's imperative to allow_all_  users of Eglot with
> > > Emacs 29 to upgrade to Eglot 1.14 (and 1.15, 1.16, etc., when those
> > > become available), then we should release Emacs 29 with 1.14.
> >
> > Was this question about stability only?
>
> It was about the criteria for which versions of core packages to ship
> with a release.

I don't think we can get a single set of criteria across core packages.

E.g. Org is developed externally, has its own community of significant 
size, and does split off release branches (with additional testing, I',m 
guessing).

Eglot, OTOH, is developed only here, with no additional release workflow 
other than what MELPA/GNU ELPA historically provided: collect up some 
features/fixes, bump the Version header, and push a new release out to 
the users. The lack of extended testing period is made up for with the 
capability to push out a new fixed version overnight. That's why the 
difficulty in upgrading to the latest version (for Emacs 29 users) is 
going to hurt.

BTW, if you recall the threads before Eglot was added, I was against 
that, and one of the things I cited is an LSP client has inherently high 
development velocity. Maybe the LSP community will settle/mature/stop 
adding features one day, but it's not there yet.

> > Because since we've decided in favor of stability of package.el, and
> > against eglot's easy upgradability, I would suggest to backport Eglot
> > 1.14 to emacs-29.
>
> I won't object.  In fact, I asked up front why not.

Note that that suggestion comes with a fix to eldoc which you so far 
have rejected for emacs-29.