Re: Stability of core packages

[David Masterson <dsmasterson@gmail.com>]

David Masterson <dsmasterson@gmail.com> writes:

oops ignore this 

> 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