[Top][All Lists]

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

Re: Guix minor version update?

From: Julien Lepiller
Subject: Re: Guix minor version update?
Date: Tue, 21 Jan 2020 12:43:26 -0500
User-agent: K-9 Mail for Android

Le 21 janvier 2020 08:32:00 GMT-05:00, zimoun <address@hidden> a écrit :
>Currently, the proposed Guix to install is v1.0.1. This very version
>has some "bugs" [1] fixed since then [2]. But it is not convenient
>when using with Docker [3].
>Why not update the minor version to v1.1?
>Then, I propose to update this minor version:
> - each time core-updates or staging is merged
> - each time the bootstrapping toolchain is updated
> - each time major archives (Bioconductor) is updated
> - each time CLI is improved (time-machine, etc.)
>Ludo "disagrees" [4], kind of. ;-)
>I guess semver doesn’t apply to Guix taken as a whole, so version
>numbers should be chosen to suggest how “different” the new release is.
>That’s pretty subjective, though.
>Let collect some ideas. :-)
>Even if version is not really meaningful when speaking about Guix
>because rolling etc. I find useful to bump the minor version more
>often, IMHO, for 3 reasons:
>1. Changing the (minor) version attracts interest and increases
> 2. It helps people --mainly HPC sysadmins-- to better trust "Guix
>rocks!" because jumping from version to version fits more what they
>3. It eases to navigate through all the packages and their version
>What people think?
>All the best,

I agree releases are too far apart, when we have all of these new things to 
show off to newcomers :)

Your proposed release cycle seems too short for me, especially since a release 
is a huge drain on our resources (we try to freeze the distro, fix packages, 
make sure we retain substitutes for that version "forever", …).

We should definitely keep releases far from core-updates merges and co. That 
would ensure we have time to fix the aftermath.

reply via email to

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