Re: Allowing rolling release packages on ELPA

[Stefan Kangas]

Jostein Kjønigsen <jostein@secure.kjonigsen.net> writes:

> On 24.10.2022 08:14, Bozhidar Batsov wrote:
>> The patch seems fine to me, but I'm a bit skeptical about the whole
>> rolling releases idea in general
>
> This is the default operation for MELPA,

Yes, and that is unfortunate, in my opinion.  It is fine as an option,
but I don't think it is the best default.

There are different schools of thought here, but this is my take:

When I upgrade my packages, I want to get a known-good version, not
whatever happens to have just landed on the master branch.  I tried the
other way for years (with daily updates, etc.), and I eventually reached
the conclusion that I just don't have the time to deal with the breakage
in any of the nearly 100 packages that I have installed.  I'm happier
when I can just get my work done.

So in my experience, the argument that rolling releases "works well in
practice" has sadly not turned out to be true.

I also note that not making proper releases places an undue burden (and
in the long run probably unsustainable) on GNU/Linux distributions that
want to package and ship a known-good version for their stable release.
For more about this issue, please see:
https://github.com/melpa/melpa/issues/6656#issuecomment-584467891

For many packages, development is slow enough that the latest commit is
also always the latest release.  The right thing in those cases, in the
case of (Non-)GNU ELPA, is to update the "Version" header on every
commit.  It is trivial to do so automatically, for example with an Emacs
hook.  So it is already the case that not much extra work should be
needed for those package maintainers that strongly prefer a rolling
release model.

For these reasons, and others, I'm not convinced about the need for
adding specific support for the rolling release model to (Non-)GNU ELPA,
outside of the devel archives.  At the very least, we should think very
carefully about it.  Perhaps we should give it a couple of years to see
what kind of influence NonGNU ELPA will or will not have on the habits
of ELisp package maintainers.