Re: Stability of core packages (was: Not easy at all to upgrade :core packages like Eglot)

[Eli Zaretskii]

> Date: Thu, 20 Apr 2023 16:03:16 +0300
> Cc: joaotavora@gmail.com, emacs-devel@gnu.org
> From: Dmitry Gutov <dmitry@gutov.dev>
> 
> On 20/04/2023 12:47, Eli Zaretskii wrote:
> 
> >>> Also, does package.el support "downgrading" to the bundled version?
> >>> Did anyone actually try that?  In particular, what happens with the
> >>> dependencies the user upgraded together with the package being
> >>> "uninstalled", due to the minimum requirements of that package?
> >>
> >> It should work by "uninstalling" the package. An when you uninstall a
> >> package, package.el warns you about any dependencies that would be
> >> broken this way. Someone should test it just in case, of course.
> >>
> >> But the important part is that the bundled package stays installed. You
> >> asked why we can encourage people to upgrade said packages freely. One
> >> answer is that they have a safety net.
> > 
> > All those differences disappear when we are discussing core packages.
> > Which is my only focus in this discussion.
> 
> Disappear, why? The core packages are the only kind of "bundled" 
> packages we have (for now), and so they are the only ones that can be 
> safely reverted to the bundled version via uninstallation.

Exactly.  That answers your 'why?" question, AFAICT.

> Let me try again: one of the uses of ELPA is to push out the package 
> release "into the real world" so that more people can test it.
> 
> So that "N weeks later" we can consider is "stable" and be content to 
> have it in an Emacs release.
> 
> By the very definition, the same release wasn't "stable" N weeks ago, 
> just as it was published. So ELPA cannot be considered to have the same 
> level of stability because we also use it for testing this way (among 
> other things).

Perhaps there's some kind of misunderstanding here.  To me, declaring
a version of a package "stable" just means some label in its metadata,
which is exposed to package.el and to the users.  So when the package
developer decides that "N weeks have passed", he or she will add that
label, thus making the corresponding version be considered "stable".
Next time users check for updates they will see that, and could then
upgrade to the "next stable" version if they so desire.

IOW, the version on ELPA that wasn't "stable" before, and was used for
testing, now becomes "stable".

Am I missing something here?

> But note that as per above, if we wanted ELPA to be the "stable" source, 
> we'd need some other testing ground before pushing releases to it.

For core packages, that testing ground is the master branch.  Exactly
as for code in Emacs itself.  Once a version is declared "stable", its
changes will be cherry-picked to the Emacs release branch, thus making
it part of the future bug-fix release.

> E.g. 
> we could just wait for people using the master branch to report 
> problems. But since there are fewer of them than there are ELPA users, 
> it stands to reason that the stabilization periods must become longer. 
> Maybe not two years, but longer than with ELPA.

Why do you assume that people who use the Emacs master branch don't
use core packages? or that there are fewer of them than those who use
the release branch?  And, since the code of the core package that is
on master is also on ELPA, I don't see how we can lose any testing,
because reports from users who use non-"stable" versions from ELPA are
as good as from those who use the package via the builds of the Emacs
master branch.  So nothing is lost here, not that I could see.

> >>> Users who must have these features (presumably because they must use
> >>> servers which require that) will have to give up some stability
> >>> expectations.  Exactly like users who must have some new enough
> >>> feature of Emacs which is only available on the master branch.
> >>>
> >>> So once again: what is fundamentally different or new about packages
> >>> which develop at fast pace, in the context of this discussion?  Why do
> >>> we need to bring up those details here?
> >>
> >> It's an issue of whether a "stable" Eglot could actually be useful 2
> >> years later for most people.
> > 
> > "Two years" because you think the release frequency of Eglot will be
> > slowed down to such abysmally low value?  As explained above, I think
> > this is not going to happen, so there's no need to assume this will be
> > the outcome.
> 
> No, no. I'm talking the scenario with users who are going to stay with 
> the version of Eglot that comes with Emacs 29, for two years without 
> upgrading. That might not be wise in a lot of cases (admittedly, this is 
> just a guess at this point, looking at the speed of changes around the 
> community), so we should make it easy to upgrade.
> 
> I don't believe the upgrade must be made automatic, however.

Users of Emacs 29 that need a newer Eglot don't need to stay with the
version we shipped.  First, if the machinery to promote Eglot versions
to "stable" status is in place, bug-fix 29.x releases could have newer
versions of Eglot bundled with them; our rate of putting out bug-fix
releases is much higher than once every 2 years.  Users who cannot
wait until the next bug-fix release, but still want stability, will be
able to upgrade their Eglot to a newer version, provided that we mark
some newer version on ELPA "stable" after "N weeks" or so.  Finally,
users who want newer Eglot badly and are willing to sacrifice some
stability will update to the latest-and-greatest version on ELPA, even
if it is not "stable" yet.

So I don't see how this can lose, if we indeed have the above system,
or something like it, in place.