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

["João Távora" <joaotavora@gmail.com>]

On Fri, Apr 14, 2023 at 1:34 PM Robert Pluim <rpluim@gmail.com> wrote:

> So on master if I upgrade all packages, ':core' packages would be
> automatically upgraded as well?

By definition, all :core packages in master are already at their
newest version.

> I strongly object to that as a
> default; just because thereʼs a newer version on elpa of a :core

I really planned to sit this one out, but I'd like to make
sure people understand the implications of what they're asking for.

On Emacs 26, 27, 28 if the user has

  (package-install 'some-package-now-in-core)

in her configuration, it gets upgraded to the most recent version
there is.  In subsequent forms, the config can start doing stuff with
the variables and definitions in 'some-package-now-in-core', etc.
And the user can enjoy the newest features and bugfixes.

On Emacs 29 and later, the very same config will do nothing
and even probably/possibly break with an error.

Furthermore, the subtle problem will grow more serious and
bizarre as time goes on and "some-package-now-in-core" evolves.
It might not break for users who upgrade to 29 next month
and break for users who upgrade to 29 in 6 months' time, because
"some-package-now-in-core" will have evolved significantly.

> package doesnʼt mean emacs should upgrade to it unless *explicitly*
> told to do so.

I really don't understand why M-x package-install RET
<types-name-of-package> RET isn't explicit enough.  But I guess a
a confirmation prompt could be logical.  I haven't followed
all mails, maybe someone has proposed that?

As for non-interactive package-install, I guess that finding an
explicit `package-install` somewhere in the configuration is reason
enough to assume that the user meant for it to have the meaning
and effect it has always had before she upgraded to a version
where the same package happens to be in :core, and that meaning is
"upgrade to the newest".

João