Ricardo Wurmus <rek...@elephly.net> writes: > Suhail Singh <suhailsingh...@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