To be clear - I'm arguing against rolling releases, just pointing out they require a bit
of due diligence on their maintainers part. But if someone requested this explicitly I guess
we can assume they know what they are doing.
I'd say this approach is quite feasible, there are even popular GNU/Linux
distributions out there who don't do big timely releases, but have
rolling package updates, one of them I've been using for years with zero
issues.
This generally relies upon development and deployment being supportive
of it.
Some developers prefer to do development in separate branches. Git makes
this cheap and easy to the point of being free. When features/bug fixes
are good enough they can be safely merged to master with little to no
effort. Emacs itself does this quite often for big features
(native-comp, pgtk, tree-sitter). This way master is almost guaranteed
to be 'green'.
IMO the status quo is a good default, but having an option of rolling
updates is good for developers that follow branched development.
> 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. 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).
>
>
> 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?
>>
>> 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?
>>
>> 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.
>>
>>
>> --
>>
>>
>>
>>
--