Re: Stability of core packages

[Eli Zaretskii <eliz@gnu.org>]

> From: Mohsen BANAN <emacs@mohsen.1.banan.byname.net>
> Cc: emacs-devel@gnu.org, João Távora
>  <joaotavora@gmail.com>
> Date: Sat, 29 Apr 2023 14:47:51 -0700
> 
> >
> > I've read this several times, and I admit I still don't really
> > understand the suggestion.  Maybe it's because you are using some
> > terminology without explaining it in enough details, perhaps because
> > you assume prior knowledge of what it means.
> 
> Sorry about that.
> 
> In fact, that is the case. I was assuming that you
> and others would be familiar with the lessons
> learned from the "straight.el" and doom emacs
> efforts over the past many years. My apologies.
> [...]

Thanks.  I think I understand now what you are proposing.

However, this is not what the current discussion thread was about.
You are describing the technical means of tracking the collections of
versions/snapshots/commits of packages that are known to work well
with a given release of Emacs.  By contrast, the issue I raised, which
I think is a prerequisite for selecting any such technical means, was:
what are the levels of "package stability" we want to support, and
what are the criteria for each supported level?  Once we have that
figured out and agreed-upon, we can proceed to discussing how to
support those stability levels from the technical POV.

> Eli, if you have not used straight.el, I suggest
> experimenting with it.

Sorry, I cannot afford that: not enough time left, after all my other
duties here are done.

But I don't think I need to do that in order to understand what you
are proposing.  For that matter, I don't really see a significant
difference between explicit versioning of package releases and using
commits/tags for the same purpose.  After all, a version is just a tag
in the repository, i.e. a label of a commit.  So they are all
equivalent.  And since in practice the only source of stability data
of a package is the maintainer(s) of that package, the reason for
using commits instead of release version tags seems weak to me;
moreover, it assumes some significant team of people unrelated to any
package that keeps track of stability and dependencies of a large
number of packages, something that IMO is impractical for Emacs.

But as I said: these are secondary issues, from my POV.  We are not
yet at a point where these issues are of any practical importance for
our package system.  And one more thing to keep in mind: these issues
are from my POV most important for the so-called "core" packages,
which are those that need to be shipped as part of the Emacs release
tarball, but are developed and maintained outside of emacs.git.  None
of the package systems you mention have ever faced and handled this
situation (with the possible exception of XEmacs, years ago, but we
all know where that went...).