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

[Dmitry Gutov <dmitry@gutov.dev>]

On 20/04/2023 17:03, Eli Zaretskii wrote:
> 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".

Okay. That can work if:

- We're able to force at least some older versions of the package to 
stay around in the repository. And we'll probably need some new UI in 
package.el to be able to choose among the versions.

- We're able to retroactively add some metadata to already published 
versions, like calling some older one "stable" after some time has passed.

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

That's fair.

> Users who cannot
> wait until the next bug-fix release, but still want stabil
> 
> ity, 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 we seem to agree that the ability to upgrade is important as well.

Whether we're able to transition to a new system with stability tags, 
etc, is yet to be seen.

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

The main downsides of this are probably obvious:

- The development work required.
- The additional ongoing package maintenance work that is implied by 
this design.

Whether it's really worth it in the end, I don't know. E.g. Joao seems 
to think that additional stable releases for Eglot won't have much of an 
audience (which seems sensible to me), but Arne's messages seem to 
indicate a preference for stability. And the larger community seems to 
be using MELPA quite happily, which is as unstable as it gets.

Maybe it won't be used much by Eglot, but Org devs take a liking to it. 
On my part, I would maybe tag a "stable" release once a year or so.