Re: On the quest for a new release model

[kiasoc5]

Hi all,

On 12/13/24 20:38, John Kehayias via Development of GNU Guix and the GNU 
System distribution. wrote:
> Hi all,
>
> On Fri, Dec 13, 2024 at 03:08 PM, Felix Lechner via \"Development of GNU Guix and 
> the GNU System distribution.\" wrote:
>
> > On Fri, Dec 13 2024, Ricardo Wurmus wrote:
> >
> > > Our releases should mean something.
> >
> > What do they mean, please?
>
> This is actually related to the topic I wanted to bring up before we really get 
> lost in the details of release building and so on.
>
> I've always thought about Guix as a rolling distribution, where our "releases" are 
> essentially installer "snapshots." In other words, the installer has maybe gotten 
> improvements and certainly been thoroughly tested along with good substitute coverage and 
> functionality across all (or as much as we can muster) of Guix. This tagged version is important to 
> make sure there is binary substitute downloads (and maybe a corresponding manual online).
>
> There is no expectation, nor really support, for staying on a "release." One is expected 
> (and warned by guix even) to occasionally at least run "guix pull" if not upgrading, 
> reconfiguring, etc. However, we do have powerful tools for staying at some particular commit, 
> through time-machine, channel pinning, and so on.

I agree with replacing the word "release" with "installer version".

On distros with stable releases (Ubuntu, NixOS, etc), there is an 
expectation for support of packages (usually security updates) for the 
lifetime of the release. Seeing that the Guix versioned branches do not 
get any additional support beyond binary substitutes and a manual for 
the purpose of installation, the word "release" is not justified at this 
time.

But if Guix "releases" just exist for the purpose of versioning the 
installer, then it is the same as how a rolling release like Arch does 
it, where the installer is versioned and users are expected to upgrade 
their system afterwards (but not necessarily the installer).

Even with tools for managing packages at a specific commit, that's 
unique to a rolling release model where each commit is exposed to the 
user. The same cannot be said for versioned releases.