Steve George <st...@futurile.net> writes: > Hi all, > > Thanks for all the feedback on the initial proposal. > > I've integrated it into the GCD so attached is a revised version. I think > it's ready to move to the Discussion Period (minimum 30 days from today). > > A short summary of the changes in this version: > > - Rename staging to integration branch with suggestion of next-master > [Zheng Junjie] > - Add benefit of updated distribution through other package managers > [Rutherther] > - Remove reference to faster initial git pull [Rutherther] > - Move target annual release to June [Rutherther] > - Reduce freeze period by breaking it up into stages [Rutherther & others] > - updates freeze (week 8->12), hard freeze (week 10-12) > - Identify pacakge sets earlier [Vagrant] > - Reword template plan to show weeks [Vagrant] > - Add alternative release target weeks to plan [Vagrant] > - Identify 'at risk' packages earlier [Greg / Andreas] > - Make automation a goal of the Release process & release team [Greg / > Ekaitz / reza] > - Reduce the scope of package sets [Jelle / Efraim] > - Provide more clarity on dealing issues in package sets [Rurtherther] > - Try to clarify options around RC bugs and package build failures > - Try to clarify purpose of release project plan as a template > > I would love to know if this improves things from any feedback that you gave? > > As well as any other thoughts, comments or ideas on how to improve this GCD! >
Hi Steve, Thanks for this great GCD! I assume the GCD would end after June, so will there be a july/august release or will we have to wait for a year? Few comments below. Have a great day, Noé > Steve / Futurile > > title: Regular and efficient releases > id: 005 > status: submitted > discussion: https://issues.guix.gnu.org/78332 > authors: Steve George > sponsors: Andreas Enge, Ludovic Courtès, Efraim Flashner > date: <date when the discussion period starts> > SPDX-License-Identifier: CC-BY-SA-4.0 OR GFDL-1.3-no-invariants-or-later > --- > > # Summary > > Guix doesn't have a regular release cycle which has led to infrequent new > releases. Sporadic releases are detrimental for our users, contributors and > the project. This GCD proposes we implement an annual release cadence and > simplify the release process to make releases easier. > > The project currently releases new versions of Guix on an ad hoc frequency. > The 1.4.0 release happened in December 2022 [^1], which is almost 2.5 years > ago, at the time of writing. > > The weaknesses in this release strategy are: > > 1. No clarity on when the next Guix release is. > 2. Releases are complex and toil for developers. > 3. Rolling updates aren't suitable for all users. > > This GCD proposes the following combined solution for solving the challenges > associated with #1. and #2. above: > > 1. Regular releases: switch to a time-based release of Guix every year. > 2. Efficient releases: use *package sets* and *supported architectures* to > reduce the scope of work required to create a Guix release. Create a > rotating *Release Team* who will organise each release, with the goal of > *automating releases* wherever possible. > > The benefits will be: > > 1. New installations of Guix will be better because installation media and > manuals will be up to date. The version of Guix distributed through other > Linux distributions will also be more recent. > 2. Package installation will improve for all users. Packages will be > ungrafted > during each release cycle. > 3. Package quality will improve for all users, because regular releases will > provide a cadence for focusing on our quality. > 4. A regular cadence for promoting the project to potential users. Helping us > to inform more people about the benefits of using GNU Guix! > 5. A regular release cycle is a rallying point for our contributors giving > them a > consistent calendar of when to focus on releases versus other hacking. > > This GCD doesn't attempt to address the challenge that rolling updates aren't > suitable for all users (#3. above). Adding a slower-moving branch akin to > Nix's stable could be an eventual goal [^2]. However, this GCD aims a single > achievable change by implementng regular releases which is a > substantial change implementing* > that would be a big improvement for our users. > > > # Motivation > > Releases are important for any Free Software project because they update the > user experience and are a focal point for excitement [^3]. Regular releases > help us to improve the quality of our software by bringing focus, and > exercising regular usage scenarios (e.g. testing the installer). > > The majority of distributions follow time-based releases, six months is a > common cycle time. For further comparison see the research on the > [release strategies of distributions] > (https://codeberg.org/futurile/guix-org/src/branch/master/release-mgmt) No space between ] and ( > . A summary is: > > - NixOS: releases every six months (May/November), both rolling release and > slower stable branch. > - OpenSUSE: rolling release, slow-roll release and fixed releases. > - Ubuntu: every six months, with 9 months maintenance. LTS releases every > 2 years. > - Debian: Every 2 years (not time fixed), with about 4-5 months of package > updates freeze before the release while bugs are ironed out. > > As a rolling release Guix immediately provides the latest improvements to > users. Consequently, it could be argued that releases are unnecessary. > However, they provide a focal point for the project to undertake additional > testing and stabilisation across the repository. They also ensure we update > installation media, documentation, themes and web site. > > 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. > > Regular releases are also good for casual users because they provide an > opportunity for us to promote new features and improvements. For prospective > users promotional activity about the release means they are more likely to > hear > about capabilities that will attract them to experiment with Guix. > > Many desktop distributions release every six months to align with the major > desktop environments (GNOME/KDE) who release two or three times a year. This > is > why Nix (May/November) and Ubuntu (April/October) align their releases. > > Since Guix is used [extensively as a desktop] > (https://guix.gnu.org/en/blog/2025/guix-user-and-contributor-survey-2024-the-results-part-1/) > it would make sense to align with these upstream releases. However, given > that > Guix is a volunteer project that doesn't have the practise of releasing it's > unrealistic to move to two releases a year. Something along these lines could > be a future goal [^5]. > > This GCD proposes an annual release cycle, with releases **in June**. > > 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 June 2026. > > > ## Package Sets > > There are currently over 30,000 packages in the archive, it's unrealistic for > all packages to receive the same amount of QA effort for a release. > > Many other distributions focus attention on the critical parts of their > repository by identifying those packages that are required for a particular > use-case. For example, Arch Linux limits their efforts to a specific > repository (called "main"). Ubuntu identifies various seeds for specific > use-cases which determines their maintained packages; other packages outside > these sets do not receive security updates. > > Guix is both a package manager that can be hosted on other Linux > distributions, > and a Linux distribution. Limiting the range of packages and services that > receive attention is consequently more complicated. Guix already has > manifests > to track which packages are used by [Guix System's > installer](https://git.savannah.gnu.org/cgit/guix.git/tree/etc/manifests/release.scm) > , so this proposal extends that concept. > > For this proposal each successive Release Team would identify key packages > which > would receive the most Quality Assurance (QA) attention in that release. > > The package sets would be: > > * minimal: packages required to boot and install a minimal Guix or Guix System > install. This would include the guix daemon, kernels, boot loaders, > file-systems and minimal utilities. > * standard: packages that create a core installation for all other uses. > * desktop: provides the packages necessary for a desktop. This would include > the smallest set required for the initial environment. > > Guix would still make all packages and services part of a release (the entire > archive). Guix teams would be asked to test the parts of the archive that > they > look after. But, only Release Critical bugs in the `package sets` would block > a release. > > Packages within the `packages sets` must build on the primary architectures > (see definition lower). As part of the release's QA contributors would be > asked > to test these packages. > > Where a significant issue is found within a package or service that's part of > a `package set` the Release Team would work to resolve the problem. This could > involve (but isn't limited to) fixing the underlying issue, documenting it as > a limitation in the release notes or promoting an alternative and removing the > broken package from the archive using the Deprecation Policy. > > Given the constraints on developers the overal aim of the `package sets` would > be for them to be as small a set of packages and services as reasonably > possible. > It would mean that developers could focus on the critical packages and > services > during a release. As an example, this would mean that a major issue in the > Linux kernel could block a release, but not an issue in a game. > > > ## Platforms and Architecture tiers > > Guix is built and maintained on multiple different architectures, and two > kernels (Linux, GNU Hurd). As the goal of the project is to maximise user > freedom this variety is significant and is a key motivator for developers. > > However, with limited resources (developer and CI) we want to make it as > efficient as possible to create a release. The more toil involved in a > release > the less likely developers are to work on it. > > The [2025 Guix User > Survey](https://guix.gnu.org/en/blog/2025/guix-user-and-contributor-survey-2024-the-results-part-2/) > showed that 98% of users were on x86_64 and 19% on AArch64. Consequently, the > proposal is the following tiers: > > - Primary architectures: > - Architectures: x86_64, AArch64 > - Kernel: Linux > - Coverage: all packages and services that are not explicitly platform > specific must work to be included in the archive. > - Package status: package updates should build for this architecture. If a > package update is broken it must not be pushed to users (e.g. master). > - Security: all packages that are maintained upstream receive updates > > - Alternative architectures > - Architectures: all others > - Kernel: Linux, Hurd > - Coverage: all packages and services that are not explicitly platform > specific may build > - Package status: package updates should work for this architecture. > Updates that do not build for this architecure, but do build for a primary > architecture may be pushed to users. > - Security: no commitment to providing security updates for this > architecture. > > Packages or services that do not build for the Primary architectures as part > of > a release would be removed from the archive using Guix's deprecation policy. > > > ## 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 > > 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. > > > ## Release team and project > > A regular release cycle should galvanise all Guix developers to work on our > releases. But, to ensure there are sufficient people involved a call will be > put out to create a specific release team for each release project. We would > expect the final release team to be around four-six members. The release team > will work together to fix issues and test the various release artifacts. The > expectation is that the release projects will be as short as possible, around > a 12 week commitment with each team member having a few hours a week to take > part. > > The project would like to achieve releases with the minimum amount of effort > by developers. Consequently, a goal for each Release Team is to find ways to > **automate releases** reducing the toil of successive releases. > > To manage the release it's proposed that each release will have a Release > Manager > role. The role of the Release Manager is to: > > - co-ordinate the release project > - communicate with the release team and wider developers status and release > critical bugs > - arbitrate changes to release blocking bugs, package sets and release > artifacts > - influence and assist teams to resolve problems > - define the release artifacts and create them > - encourage and excite **everyone to create and test the release** > > The Release Manager role is likely to require the most effort, so it will be > rotated and consist of two people from the release team. For each release > there would be a primary person and a secondary person in the role. The > primary person is new to the role. The secondary person has previously done > it > and is mentoring the new person. The impact of this is that each new release > manager is agreeing to take responsibility during two release cycles. > This system is modelled on the [Nix release > management](https://codeberg.org/futurile/guix-org/src/branch/master/release-mgmt/nix-release-mgmt.md) > approach. > > One of the release team will take on the role of Release Advocate [^6]. They > will take responsibility for preparing the release announcement and > coordinating the creation of content to promote the new release (e.g. web > site) > This role can be done by any member of the Guix community who has sufficient > interest. > > The final release team is: > > - a new Release Manager > - a returning Release Manager > - up to 4 other members, one of whom acts as the Release Advocate > What happens in 6 years when there are no new release managers available, can we reuse someone? > The Release Managers of each release will create and communicate a release > project plan setting out the stages and dates for each stage. To try and > galvanise the Guix development team to focus on the release it's envisioned > that a release project will be about 12 weeks. See Appendix 1: Release Project > Template for an example. > > In order to improve knowledge transfer and reduce the toil of doing releases > the Release Managers for a release will document the release process. There > is > inspiration for this in [NixOS's release > wiki](https://nixos.github.io/release-wiki/Home.html) > and we already have detailed [release > documentation](https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/doc/release.org) > . > > > # Cost of Reverting > > If regular releases were not successful then the project would switch back to > irregular releases. There would be no impact for exiting users as they will > be tracking the rolling release's master branch. > > If the project is able to successfully undertake regular releases then over > time it may be possible to undertake full releases every six months or some > other release cadence. > > > # Drawbacks and open issues > > There's no particular drawback to attempting regular release. It should be > noted that the project is entirely dependent on volunteers so it may be that > contributors don't have enough time available to achieve regular releases. If > that's the case we would revert back to irregular releases. > > Appendix 1: Release Project Template sets out a proposed time-line and major > steps to be undertaken by the project to release a new version of Guix. It > proposes freezing master while the team focuses on releasing the new version > of Guix. Specifically, a major updates freeze (week 8->12), and a hard freeze > (week 10->12). The drawback of this approach is that it would slow the > velocity of changes. During this period contributors would have to keep > updates on team branches, or use an alternative temporary branch. Each > Release > Team will iterate and improve the release process, so it's possible that this > freeze period will be reduced, changed, or removed over successive releases. > > There are various improvements that could be made to the release strategy over > time, such as adding an additional slower release cadence. > > > # Appendix 1: Release Project Template > > To show the major steps of a release this release project template is a > starting > point. After each successive release the Release Team will undertake a > retrospective and will document improvements that can be made to the release > process and areas to automate to improve efficiency. > > The aim in this template is for a 12 week active release project, with the > first > one using 16 weeks in total to give teams time to prepare. > > The current outline builds from our current [release > document](https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/doc/release.org) > > | Week of Project | Event | > | --- | --- | > | -5 | Nominate a release team | > | -4 | Notify teams of upcoming release | > | 01 | Release project start | > | 03 | Package set finalisation | > | 04 | Toolchain and transition freeze | > | 06 | Initial testing | > | 08 | Major updates freeze | > | 08 | Breaking changes to next-master | > | 08 | Ungraft master branch | > | 09 | Bugs and documentation focus | > | 09 | Branch and tag release branch | > | 10 | Testing and hard freeze | > | 10 | Release candidate | > | 12 | Final release target | > | 14 | Alternative release target #1 | > | 16 | Alternative release target #2 | > | +1 | Integration branch merged to master | > | +2 | Release retrospective | > | +2 | Relax - it's done! | > > ### Nominate a release team (week -5) > Nominate a release team with two Release Managers (1 is the previous RM), and > up to 4 other people who will work on the release. Put out a call for a > Release > Advocate who can be anyone in the Guix community who's willing. > > ### Notify teams of upcoming release (week -4) > Make sure all teams are aware of the upcoming release. This gives them 4 > weeks > to undertake any large transitions or major changes. > > ### Release project start (week 01) > Start the project with weekly updates to guix-dev and regular meetings of the > release team. Encourage participation in testing and identifying bugs from > the community. > > ### Package set finalisation (week 03) > Specify the package sets for this release. The Release Team will identify all > packages and their inputs so that a full manifest for the release is created. > > Packages that do not build for the primary architectures so could be risk of > removal will be identified and developers will be notified following the > Deprecation Policy. > > ### Toolchain and transition freeze (week 04) > 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 are accepted after this point. Packages > and services in the 'minimal' package set should not be altered. > > ### Initial testing (week 06) > An initial testing sprint to look at packages, services, install media and > upgrade testing. This should identify: > > * packages or services that may need to be removed because they fail on a > primary architecture > * packages and services in the package sets install and can be used > * installation artifacts can be created and used > * example system definitions can be used > * system upgrades > > Update the list of packages that's at risk of being deprecated following their > identification in `Package set finalisation`: see if these build failures have > been resolved. > > A build failure of a package or service that's in a package set will be marked > as a blocker for the release: Release Team to make determination on response. > > ### Major updates freeze (week 08) > Major package updates are frozen on 'master' as the focus is on fixing any > blocking packages. **Security updates still go to 'master'**. > > All major changes not related to the release remain on team-branches. > > Team branches can still be folded into the release branch as long as changes > are > minor package upgrades. > > ### Breaking changes to an integration branch (week 08) > If there are major breaking changes that must be moved from a team branch an > integration branch will be created. For example `next-master`, this will be > short-lived, existing only until after the release. > > The master branch slows down from this week until the release. > > This concept comes from the Nix project where they flow big changes into a > staging branch while they do release stabilisation to prevent big flows of > breaking changes into master which broke one of their releases [^7]. > > ### Ungraft master branch (week 08) > Guix master is ungrafted to minimise the difference with users of the release > initial 'guix pull' experience. > > ### Bugs and documentation focus (week 09) > The master branch should be quiet at this point as everyone should focus on > testing and resolving any bugs. New documentation can also be done. > > ### Branch and tag release branch (week 09) > The master branch is tagged and a new release branch is created. > > * master branch: security only. > * release branch: security updates as normal. Only RC blocking bugs. > > Only security updates go to the master branch from this point. All other > changes stay in a team branch or go to an integration branch. The focus on > the > release branch is to stabilise so only resolutions to bugs should be pushed. > > ### Testing and Hard Freeze (week 10) > Release Crictical (RC) bugs and issues should be solved for the release > branch. > > Only changes that will fix a non-building package, or a RC bug in a > package/service are allowed. Ideally avoid new upstream versions, but it's > acceptable to use a new minor upstream version to solve a bug. > > Any non-building packages are removed using the Deprecation Policy. > > Call for testing from all developers and users: goal is to test the main > installation use-cases and packages within the `package sets`. > > ### Release candidate (week 10) > Release artifacts are created for the release candidate. There's a final 2 > weeks of testing with these artifacts. If there are no release blocking bugs > discovered then the release uses these artifacts. If bugs are found/fixed > then > release artifacts are regenerated as needed. > > ### Final release target (week 12) > Final release is targeted for this date. All planning and work should be done > to this date. > > The new release is announced and new release artifacts are published. > > If the Release Team determines that release has Release Critical bugs without > workarounds they may move the release to Alternative release target #2. > The concept of buffer weeks to ensure the release balances time and quality > comes from [Fedora's release > plan](https://docs.fedoraproject.org/en-US/releases/lifecycle/#_release_dates) > > ### Alternative release target #1 (week 14) > This release target date may be used if the Release Team determines that there > were Release Critical bugs without workarounds at the Final release target > date. > > If the Release Team determines that release has Release Critical bugs without > workarounds at this date they may move the release to Alternative release > target #2. > > ### Alternative release target #2 (week 16) > This release target date may be used if the Release Team determines that there > are Release Critical bugs without workarounds at one of the previous target > dates. > > If the Release Team determines that the release has Release Critical bugs > without workarounds they may move the release to an alternative date or cancel > the release. > > ### Integration branch merged to master (release +1 week) > If there were any breaking changes placed onto the integration branch > (e.g. `next-master`) then these can be merged into the `master` branch at this > point. The master branch then continues as normal. > > ### Release retrospective (release +2 weeks) > A retrospective is undertaken by the release team to understand how the > release > process can be improved to make it more reliable for users and > easier/efficient > for developers. > > ### Relax! (release +2 weeks) > The release has been cut, everyone is now excited, and hopefully all is well. > Take some time off from release work! There's some time built-in here to > relax and get back to other hacking before it's time to start again with the > next release. > > --- > > [^1]: https://guix.gnu.org/en/blog/2022/gnu-guix-1.4.0-released/ > > [^2]: Examples of distributions that have cadences for different users and > screnarios > are Nix's stable branch, OpenSUSE's SlowRoll branch and Ubuntu's LTS > (Long Term Support) releases. > > [^3]: the aspect of creating news and excitement for casual users is > well-known > in the FOSS community. An example from > [GNOME's earlier > days](https://mail.gnome.org/archives/gnome-hackers/2002-June/msg00041.html). > > [^4]: GuixDays 2025 release discussion brought up examples of Guix not being > used to teach users because the initial pull was so slow that the > teaching session would have completed before 'guix pull' would finish. > We know guix pull being slow was identified by users as a challenge. > > [^5]: OpenSuse has a [SlowRoll > branch](https://en.opensuse.org/Portal:Slowroll) > where they release a smaller set of package updates on a monthly basis. > This is an interesting innovation as it allows users to still benefit > from > a rolling release but at a slower rate of change (fewer regressions). > They are also not dropping too far behind the rolling release, so > there's > not as much maintenance for OpenSUSE developers dealing with an out of > date release branch and having to backport software. > > [^6]: Nix has the concept of a [Release > Editor](https://nixos.github.io/release-wiki/Release-Editors.html) > who is responsible for improving the legibility of the release notes. > Our > version extends the idea to make sure other artifacts and activities > that > promote the release happen. > > [^7]: > https://github.com/NixOS/rfcs/blob/master/rfcs/0085-nixos-release-stablization.md
signature.asc
Description: PGP signature
