Re: Stability of core packages

[David Masterson]

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.

[...]

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

How would Emacs deal with those system layers.  In theory, Emacs
packages could depend on packages outside of the Emacs layer (system
libraries or other language tools).  My thought is that you'd either
have to be explicit all the way up the tree (making it a logistical
nightmare) or you'd have to prune the tree (making the definition of a
release intentionally fuzzy).

Currently, the model is that each package (supposedly) calls out it's
package version dependencies that it has been tested with and assumes
that later versions are compatible.  Isn't the above approach going to
devolve into this?

How does doom handle it?

-- 
David Masterson