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

[Eli Zaretskii <eliz@gnu.org>]

> From: "Dr. Arne Babenhauserheide" <arne_bab@web.de>
> Cc: Jim Porter <jporterbugs@gmail.com>, Eli Zaretskii <eliz@gnu.org>, Dmitry
>  Gutov <dmitry@gutov.dev>, emacs-devel@gnu.org
> Date: Wed, 19 Apr 2023 14:13:40 +0200
> 
> João Távora <joaotavora@gmail.com> writes:
> 
> > A. The effects of the form (package-install 'eglot) moving from
> > Emacs 26,27,28 to Emacs 29 are drastically different.
> > That's bad stability.
> >
> > B. The effects of, say, the form (package-install 'xref) moving
> > from Emacs 28 to Emacs 29 are the same.  That's good stability.
> >
> > What I'd like to know if anyone else thinks, like me, that this is
> > a problem.  We can discuss how bad of a problem (I think it's
> > moderately serious).
> 
> To me any breakage in behavior when updating to a newer version is
> serious. I use Emacs for many scenarios, and some of those I only touch
> twice a year (when I give a lecture and update slides for it), while
> others I might not use for 3 years until I go back into that old Python
> package.
> 
> Usually when I get in there and someting is broken in my Emacs that I
> didn’t see otherwise, that’s very painful, because I’m often under time
> pressure (like “the lecture is tomorrow and I just realized I have to
> change these slides, but with the new version I’ve been using for half a
> year the layout of just exactly these slides is broken and I still have
> to make dinner for the family and actually get some sleep afterwards!”).
> 
> But there are too many different tasks to actually check them all every
> time I update. And I usually don’t choose to do an Emacs update, but
> just update when my distro ships the new version.

I don't think anyone will argue that breaking changes are good.

But that is not what was difficult about the particular case João is
talking about.  In that case, any solution that was proposed had a
potential to break someone's workflow.

Specifically, users of Emacs 28 and older, who had Eglot installed,
and expect Eglot to be automatically updated upon Emacs startup
whenever a new Eglot version is available, will now have their
expectations broken after they upgrade to Emacs 29, because Eglot is
now a built-in package, and package.el won't by default upgrade a
built-in package.

OTOH, the proposal to change package.el so it automatically updates
built-in packages as well would break the workflows of people who
don't expect built-in packages to be updated: they would suddenly see
packages like ElDoc or Xref or Project (and others) being updated
automatically at startup instead of staying at the version shipped
with Emacs.

So there's a dilemma here: which of the two groups of users to break?

And that is the real issue here, at least from my POV.