Subject: Re: GCD005: Regular and efficient releases

From: Andreas Enge <[email-masked]>
Date: Sat, 10 May 2025 11:15:05 +0200

Hello Ekaitz,

Am Sat, May 10, 2025 at 12:59:32AM +0200 schrieb Ekaitz Zarraga:
> Steve, you asked for my thoughts, and here they are: probably not what you
> expected (:

thanks for your contribution, which brings up some interesting thoughts;
they sound provocative, but I find it useful to step out of the box and
ask the question: "do we need releases at all?". (Which goes a little
bit beyond what you actually suggested.) And one possible outcome of our
GCDs is that in the end, we decide the problem they try to solve is not
really a problem, but the GCD process has allowed us to come to this
joint conclusion and thus to move forward as a project.

Indeed if we have lived without releases for a long time, it is because
the rolling model makes them less pressing: As long as one can install
any Guix version at all, one can do a "guix pull" afterwards and be
up to date.

An automatic release process would solve some of the problems that
motivated this proposal: Debian could package the latest release no matter
how it was obtained; "guix pull" would start from a point closer to the
current master branch; and so on.

What is added by a manual release process, in my opinion, is quality
control. While the master branch is supposed to be in perfect shape all
the time, it actually is not:
- Sometimes there are breaking changes with problems only discovered
  afterwards. For instance, the move to a non-privileged daemon caused
  problems which are being solved now. Hopefully such a breaking change
  would not make it into a release due to the freezing period.
- Ungrafting is a big issue that would be done during a release, and
  the past has shown that it cannot be done completely automatically
  (sometimes things break when ungrafting). Currently on a high-speed
  Internet line it may take more time to graft the packages than to
  download them.
- Recently when updating a package and checking which dependent packages
  it would break, I noticed that several of them (!) had not been built
  for years (!), and nobody had taken the time to fix or remove them.
  Filing removal requests resulted in them being fixed or removed, and
  a better quality of Guix (in a very small niche) and easier
  maintenance: now doing a "guix build -P 1 this-package" actually tells
  whether this-package update breaks anything or not.

These are things we *could* do any time, but which are probably not much
fun, and so they are not done. Crafting manual releases means we *must*
address such problems and face our quality issues.

This could also be a first step towards an additional stable branch,
which people have called for, on which security updates and (to be
discussed) limited package updates could be made. This is outside the
scope of this GCD, but I think that quality based releases on a certain
schedule are a prerequisite.

Clearly we could not (or would not like to) do security updates on a
branch as old as our 1.4 release; and it would also not work in your
alternative model in which, if I understand it correctly, releases would
be made essentially by putting a 3 digit version number periodically on
git commits, which would essentially be a purely rolling model.

Andreas