On Tue, 10 Sep 2024 18:21:17 -0400 Greg Hogan <c...@greghogan.com> wrote:
> With Guix embracing the chaos of rolling releases, and a presumption > that users will `guix pull` soon after installation, I count only > three motivations to tag a new release: 1) replacing an old release > with an outdated Guix unable to self update, 2) security fixes for > installation packages so as not to be immediately pwned, and 3) > minimizing the number of replacement installation packages (especially > after core packages updates). There is also at least 1 project (GNU Boot, which I'm involved in) that currently uses a released Guix version (Guix 1.4.0 for i686) to build other software as the Guix manual for the latest release is easily accessible and doesn't change much, so contributors can easily refer to it. It's not a big issue to workaround some things on top of a release but if a complete language that we use is missing that creates a lot of complications for us. Bitcoin can also use Guix to build things but they seem to use an arbitrary revision not based on any releases (guix 1.3 with lots of commits on top). I've no idea if there are many other projects that reuse Guix fixed revisions. Another thing that may be relevant (not related to projects I'm involved in) could be to somehow validate if all the architectures supported by Guix work fine and maybe get important packages working on them. Though note that I'm not a Guix maintainer and I don't have commit access, so I can't participate in decisions on what is important or not. Denis.
pgp1VDgAZqngp.pgp
Description: OpenPGP digital signature
