Re: Allowing rolling release packages on ELPA

[Philip Kaludercic]

"Bozhidar Batsov" <bozhidar@batsov.dev> writes:

> Instead of setting version numbers manually (e.g. 0.1, 0.2) upon
> release time, with rolling releases every change (commit) pushed
> upstream results automatically in a new release and a version bump,
> with the version being a timestamp.  

Not quite, the time stamp is appended to the regular version number.

>                                      E.g. if I push 3 commits one day
> with some time between them this will result in 3 releases. I think
> it's a great approach for snapshot (devel) repos, but I'm not so sure
> about "stable" repos, as it kinda of implies that the author will
> never have their project in an inconsistent state (e.g. halfway
> towards a new feature).

Right, so it would only be used whenever a package author prefers that
method of development.

> This approach was made popular by https://melpa.org/ 
>
> On Tue, Oct 25, 2022, at 11:14 PM, Richard Stallman wrote:
>> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
>> [[[ whether defending the US Constitution against all enemies,     ]]]
>> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>> 
>>   > I have heard from people who prefer a rolling release model for their
>>   > packages,
>> 
>> Can you explain what that means, concretely?  How is t different from
>> what we do now?

It is currently necessary to bump the version tag in the package header
to indicate that a release is to be made.  If a package specification
has a non-nil :rolling-release tag, then this is done whenever the
repository is synchronised.

>>               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.
>> 
>> Is this something we would _want_ to do?  What would its implications
>> be for Emacs?

It wouldn't affect Emacs, just packages that request this kind of
release management.

>> We might decide to support their style of release, or decide not to
>> include their packages in NonGNU ELPA, or we might come up with
>> another solution.  I don't know what's best.  But I'm sure we should
>> think about that before we decide.

If the only issue a package has is that it is developed using a "rolling
release" model, it would be nonsensical for us to not accommodate the
request and reject a (perhaps popular) package on that ground.