Subject: Re: GCD005: Regular and efficient releases

From: Ian Eure <[email-masked]>
Date: Sun, 11 May 2025 12:18:54 -0700

Hi Steve,

Steve George <[email-masked]> writes:

> 3. Rolling updates aren't suitable for all users.

If a Guix release is a point in time snapshot of a rolling 
release, and the first `guix pull' after
installation puts you back into the rolling release model, I don’t 
think more frequent releases address this need.

> Adding a slower-moving branch akin to Nix's stable could be an 
> eventual goal as
> it would increase Guix's suitability for some users and 
> use-cases [^2].  However,
> this GCD only sets out to implement regular releases which is a 
> substantial
> change that would be a big improvement for our users.

> A specific issue caused by irregular releases is that new 
> users/installs face a
> significant first "guix pull". This provides a poor initial user 
> experience,
> and in some cases may even deter users [^4]. Additionally, it 
> requires the
> project to keep old substitutes on our servers.

It also causes user confusion becasue the assumption is that the 
release is what they should be using.  We get a good number of 
folks in #guix reading the 1.4.0 manual, which doesn’t accurately 
reflect the current state of things.

> This GCD proposes an annual release cycle, with releases **in 
> May**.
>
> To move onto this cycle the first release would be a little 
> later: aiming for
> the **November of 2025**, with a short cycle to release in May 
> 2026.

I think it’d be better to align the initial release with the 
schedule we want to keep, so if we plan for a November release, 
plan to release every November.

> ## Release artifacts
>
> Using the primary architecture tier and the package sets would 
> involve creating
> the following release artifacts:
>
> - GNU Guix System ISO image
> - GNU Guix System QCOW2 image
> - GNU Guix installer

I’m not sure what the difference is between the installer and 
system ISO image is, could you elaborate please?

> Again in an effort to reduce developer toil, additional release 
> artifacts could
> be created but would not be part of the formal release testing 
> and errors would
> not block a release.

The 1.4.0 release artifacts are[1]:

- Installer image for i686 and x86_64.
- QCow image for x86_64.
- Binary for i686, x86_64, armhf, aarch64, and powerpc64e.
- Source tarball.

Are the binaries and source tarballs "additional release 
artifacts?"

> ### 4. Toolchain and transition freeze
> No major changes to toolchains (e.g. gcc-toolchain, rust-1.xx) 
> or runtimes
> (e.g. java).  There should be no changes that will cause major 
> transitions.
>
> Debian defines a transition as one where a change in one package 
> causes changes
> in another, the most common being a library.  This isn't 
> suitable for Guix since
> any change in an input causes a change in another package. 
> Nonetheless, any
> change that alters a significant number of packages should be 
> carefully
> considered and updates that cause other packages to break should 
> be rejected.
>
> No alterations to the Guix daemon or modules are accepted after 
> this point.
> Packages and services in the 'minimal' package set should not be 
> altered.

I think it’s worth considering doing this the other way around: 
instead of freezing master, cut a release branch and cherry-pick 
fixes into it as needed.  I don’t expect that development on 
non-release features will stop during the freeze, which means 
we’ll have a large backlog of work to merge once the freeze ends; 
this is a thing Guix has historically not been good at working 
through in a timely manner.

A release branch would also support longer-term stable releases, 
if we wanted to do that.

The downside is that it’s more work to cherry-pick fixes between 
branches, and there’s the potential for merge conflicts.

> ### 7. Updates freeze
> Major package updates are frozen on 'master' as the focus is on 
> fixing any
> blocking packages.  Security updates still go to 'master'.

This could prove troublesome, as the current Guix approach is to 
update packages to the version containing the fix.  Are you 
thinking that we’d maintain that, or adopt a Debian style of 
backporting fixes where possible?

> ### 8. Breaking changes to staging
> To avoid a period of time where teams can't commit breaking 
> changes, these are
> sent to a new 'staging' branch, rather than directly to master. 
> The master
> branch slows down from this week.

This is going to be difficult to manage, especially for 
contributions from those new to Guix development.

Thank you for starting the discussion!

  -- Ian