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

[Eli Zaretskii]

> From: João Távora <joaotavora@gmail.com>
> Date: Tue, 18 Apr 2023 15:02:01 +0100
> Cc: Dmitry Gutov <dmitry@gutov.dev>, emacs-devel@gnu.org
> 
> On Tue, Apr 18, 2023 at 1:56 PM Eli Zaretskii <eliz@gnu.org> wrote:
> 
> > 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.)
> 
> It's not a "must".  Eglot can work without it.  The problem happens in
> ElDoc and doesn't affect its interface.

Then what Dmitry said about Eglot 1.15 being dependent on that change
in ElDoc is not relevant to the issue at hand, which is whether Eglot
1.15 could be bundled with Emacs 29.1.

> But Eglot relies on ElDoc as a whole.  In general you can't expect
> to have new features in Eglot without some advancing of the
> infrastructure that Eglot depends on.

Understood.  My point is that if you want Eglot users to be able to
upgrade to a newer versions, you need to have compatibility layers, to
avoid the need to upgrade too many other packages, which might hamper
stability.  Otherwise, we cannot in good faith recommend that users of
stable Emacs update their core packages without a second thought.

> So there _isn't_ a way to partially upgrade a package and not its
> dependencies.

Updating a package P1 should require update of as few packages P2...Pn
as possible.  Ideally, none at all.  Users should be able to decide
whether they want or don't want to update any single package without
also needing to decide whether they are okay with updating half a
dozen of others.  This should be our goal, because otherwise updating
a package will be unsafe if you use any Emacs except master (and thus
don't care much about stability anyway).

> > We should seriously ponder these aspects, and the sooner the better.
> 
> I don't actually think there is any actual problem present if
> we all agree (as you seem to) with Dmitry's preposition that
> "there shouldn't be a single set of criteria governing core
> packages".  Then we can teach Emacs's upgrade mechanisms to
> deal with each set differently, carefully examining the
> requirements for each set.

Sure, but we need to have these sets, actually.  Right now, we don't,
not for every core package out there anyway.

> I'd like you, if possible, to also respond (here, if you prefer) to the
> points I raised in my own reply to Dmitry's message you're replying
> to.  This is the message;:
> 
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=62720#529

I didn't respond because I had nothing to say to that which I didn't
already say in response to Dmitry's message.