Re: Stability of core packages

[emacs]

I have been following this thread from a meta perspective.

The essence of the difficulty is that we are
following an established pattern that has various
weaknesses and we are now trying to adjust that pattern.

What I am suggesting breaks the existing
model. Let me start with some context.

Because we use git for everything and because it
is possible to take complete git snap shots of all
relevant packages, it is possible to easily
provide stability for the user based on snapshots.

Consistent upgrades are then possible for new
consistent git snapshots. So, based on the snapshots
the packages are not stale and remain consistent
while evolving.

This is what doomemacs does. For every package,
there is a git tag which doomemacs keeps with the
adoption of the package. The tags are guaranteed
to be consistent. With Blee (ByStar Libre Emacs
Environment) I do the same but instead of keeping
that tag with the packages, I keep central
manifests for emacs releases. So, emacs-28.1 has
its own packages manifest which can be upgraded
from time to time. All upgrades go to the
appropriate repo and get the appropriate tag based
on the manifest. I do this across all emacs
package archives -- which I see as collections of
git repositories.

If you want to go with something like this, you
have to revisit the package retrieval model.

For every release of emacs, you maintain a
separate manifest. And you keep updating that at
new releases and even in between releases. Since
all emacs archives are git based, it is possible
to apply this strategy to all of them -- where
each take care of its own consistency.

In practice, this has already happened for layers
that sit on top of emacs (doomemacs, blee). It is
a matter of adopting the higher layer model in the
core. There are already many variations on the
model of packages.el.

If you want to go with this model, much needs to
be revisited. But much will be gained.

Again, these comments only deal with the meta
topic not the at hand  Eglot topic. But, it shows
how eglot upgrades could have rolled back to
emacs-28.

...Mohsen


Eli Zaretskii <eliz@gnu.org> writes:

>> From: "Dr. Arne Babenhauserheide" <arne_bab@web.de>
>> Cc: joaotavora@gmail.com, jporterbugs@gmail.com, dmitry@gutov.dev,
>>  emacs-devel@gnu.org
>> Date: Wed, 19 Apr 2023 21:40:35 +0200
>>
>> > 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.
>> …
>> > So there's a dilemma here: which of the two groups of users to break?
>>
>> Not updating eglot until the next Emacs release shouldn’t cause breakage
>> in any other packages, right?
>
> No, it shouldn't.  With the obvious exception of the breakage that is
> already part of the current Emacs release, which we somehow failed to
> detect and fix before releasing it.
>
>> Except if a more modern eglot is a dependency of a non-built-in package.
>
> Right.
>
>> I think that’s what I would prefer: I would treat being pulled into
>> Emacs as a stabilization step that switches the package from being on
>> the latest version to being at the version in Emacs or the minimum
>> version required by dependencies — if that version is higher than the
>> version in Emacs. Basically minimize the distance from the Emacs
>> release.
>
> AFAIU, that is what will happen with Emacs 29 when it is released.
> But things might change in Emacs 30, as we are currently discussing
> what needs to be done to better support updating core packages.