Stability of core packages (was: Not easy at all to upgrade :core packages like Eglot)

[Eli Zaretskii <eliz@gnu.org>]

This discussion no longer belongs to the bug tracker, so I'm moving it
to emacs-devel and changing its Subject.  Please reply here, not
there.

For those who see this for the first time, and want more background,
here are some relevant messages which discussed this aspect as part of
the otherwise huge thread, which is only loosely related to this
particular issue:

  https://debbugs.gnu.org/cgi/bugreport.cgi?bug=62720#383
  https://debbugs.gnu.org/cgi/bugreport.cgi?bug=62720#398
  https://debbugs.gnu.org/cgi/bugreport.cgi?bug=62720#401
  https://debbugs.gnu.org/cgi/bugreport.cgi?bug=62720#410
  https://debbugs.gnu.org/cgi/bugreport.cgi?bug=62720#413

> Date: Tue, 18 Apr 2023 04:25:01 +0300
> Cc: joaotavora@gmail.com, rpluim@gmail.com, philipk@posteo.net,
>  62720@debbugs.gnu.org, larsi@gnus.org, monnier@iro.umontreal.ca
> From: Dmitry Gutov <dmitry@gutov.dev>
> 
> 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.

We don't need to have just one set.  Packages are different in both
their complexity, their dependence on other packages, and dependence
of other packages on them.  So one set is unlikely to fit the bill,
indeed.

But that doesn't mean we shouldn't have criteria at all.  We should
strive to have a small number of them, and we should know which set is
applicable to which class of packages.

This will be one of the serious issues if we ever move to having some
packages only in elpa.git, and will then bundle them when preparing an
Emacs release tarball.  It will be imperative to know at that time
which version/branch of each such package to take as part of preparing
a release.  We must have a solution by then, so this is as good time
as any to start discussing the issue.

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

If some core package is not tested enough before it gets a new
version, then why are we okay with telling users of a stable Emacs to
update the package willy-nilly as soon as another version is on ELPA?
Shouldn't we at least warn them, or, better, somehow indicate that
this version is not yet considered stable?

IOW, shouldn't packages have some "stability gradation" that is
visible when users look at the list of packages via package.el?
Shouldn't we allow users to tell package.el which stability they want
to download, so that unstable packages don't inadvertently get
installed and mess up their production environment?

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

I don't see what development pace has to do with this issue.  If a
package is being developed at a high pace, it might mean that the
stable version will lag more.  But what does this change in principle?

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

You mean, the change in ElDoc that avoids the "jumping mode line"
issue?  If so, it is unfortunate for Eglot to depend on that, because
it means users of Emacs 29 will be unable to upgrade to Eglot 1.15
without by side effect installing a newer and potentially less stable
ElDoc.  (I also am surprised that change is a must for Eglot 1.15.)

So this again goes back to the main issue: how should the stability
considerations affect development of core packages and their
"stability gradation"?  Developers of core packages should keep these
aspects in mind at all times, and, for example, avoid dependencies on
other packages that aren't absolutely necessary.  Otherwise, we will
have to advise users who value stability not to upgrade their core
packages for fear of destabilizing their environments, and the whole
advantage of having core packages on ELPA will be effectively lost, at
least for those users who want stability.

IOW, having a core package on ELPA comes with some serious strings
attached, and just ignoring them, or leaving that up to the users
(without duly informing them about their new responsibilities) is not
a good solution, IMO.

We should seriously ponder these aspects, and the sooner the better.