Re: Stability of core packages

[David Masterson <dsmasterson@gmail.com>]

emacs@mohsen.1.banan.byname.net writes:

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

-- 
David Masterson