guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: On the quest for a new release model


From: Suhail Singh
Subject: Re: On the quest for a new release model
Date: Fri, 13 Dec 2024 17:27:17 -0500
User-agent: Gnus/5.13 (Gnus v5.13)

Ricardo Wurmus <rekado@elephly.net> writes:

> Suhail Singh <suhailsingh247@gmail.com> writes:
>
>> Assuming my understanding above is correct, wouldn't you agree that
>> (even) for those individuals what's most important is that there is a
>> _stable_ and _not-very-outdated_ release available?  My (and I believe
>> Greg's) contention is that following a time-based release process
>> achieves these objectives more effectively than following a
>> feature-based release process.
>
> I agree that more frequent releases are necessary, but I don't see much
> value in “automatic” time-triggered releases.  After all, that's what
> "guix pull" already provides.  Our releases should mean something.

I was not proposing for "automatic" time-triggered releases.  I was
proposing that a periodic cadence start the _process_ of "vetting" the
release candidate.  Notably, the vetting process (particulars yet to be
decided) would be focusing on stability, test and build coverage etc.
I.e., some notions of quality.  This is something "guix pull" does _not_
provide.

I would describe the linux kernel as following a time-based release
process.  The meaningful distinction from a feature-based release
process is that the release process doesn't wait for any feature.

> Also note that Guix itself is a library.  I don't think it would be a
> good idea to inflate the number of releases.

If they are versioned according to an agreed upon versioning scheme, why
would the proliferation of versions _not_ be a good idea?

-- 
Suhail



reply via email to

[Prev in Thread] Current Thread [Next in Thread]