The patch seems fine to me, but I'm a bit skeptical about the whole rolling releases idea in general - e.g. should something like a change to the docs really result in a new release? How hard it is for people to actually update version timestamps themselves or to just stick to the *-devel repos if they don't want to cut releases?
How much was the demand for something like this in general? I can't think of any major Emacs package that does rolling releases.
> Date: Sat, 22 Oct 2022 10:31:35 +0000
>
> I have heard from people who prefer a rolling release model for their
> packages, and requested that their packages not be added for {Non,}GNU
> ELPA if they would have to update the version header manually,
> presumably on every commit. The following patch would enable ELPA
> devel-like versioning on ELPA, if enabled with a :rolling-release
> property. WDYT?
Not a comment on the patch, but the idea behind it: I find the current
arrangement between GNU ELPA and GNU-devel ELPA to give me the best of
both worlds. Users who need rolling releases can opt in to the "devel"
version: this has the upside of explicitly acknowledging that the
package is not marked as "stable".
The user can also arrange the 'package-archive-priorities' to choose
gnu-devel by default. And there is also 'package-pinned-packages' in
case they want a different archive for a given package. Example from my
init file where I prioritise regular GNU ELPA:
(setq package-pinned-packages
'((cursory . "elpa-devel")
(denote . "elpa-devel")
(ef-themes . "elpa-devel")
(fontaine . "elpa-devel")
(lin . "elpa-devel")
(logos . "elpa-devel")
(pulsar . "elpa-devel")
(tmr . "elpa-devel")))
--
Protesilaos Stavrou