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
