Hi Ian, On 11 May, Ian Eure wrote: > Hi Steve, > > Steve George <st...@futurile.net> 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. (...)
Yes, so this GCD doesn't resolve any issues with the rolling release not being suitable for all users (problem 3). An earlier version did, but following input from the sponsors I cut the GCD down to focus it and make it easeir to implement - one change at a time! That's why it refers to the idea that in future we could implement slower moving branches, or something else - something along those lines would resolve that issue - but it's out of scope for this GCD. This GCD focuses on problem (1) and (2) only. Rereading it this morning, it's not clear, so I will alter the paragraph to make it clear. Thanks! > > 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. > Agreed. > > 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. > An annual spring release would be better due to alignment in the ecosystem around stabilisation: it's beneficial to get the additional stabilisiation that the commercial distro's do and RHEL/LTS's always do a spring release [0]. I outlined this a bit more elsewhere in the thread, but can go into more detail. I personally would like us to do a release before $SPRING 2026. Doing releases more often, should help us get better at them, automate them (see comments from Ekaitz/Reza), so hopefully doing a November and then a $SPRING would be achievable. I would give shifting to a $SPRING time-frame, priority over doing the November one if it was an absolute choice, as I think that time of year is optimal. > > ## 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? > AIUI we have two install paths (product?), one is installing 'Guix System' as a Linux distribution, the other is installing 'Guix' (package manager) on a foreign distribution. For a release we update both. So 'GNU Guix installer' was refering to the Guix as a package manager, and the other two were 'Guix System'. > > 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?" > Yes, good catch. I'll add 'GNU Guix Source tarball', I believe that the existing 'GNU GUIX installer' covers the binary point. This section is covering the minimum created artifacts, which would be the focus of developer work and testing. Nothing stops additional artifacts being created - for example the latest downloads page (https://guix.gnu.org/en/download/latest/) has a Pinebook Pro image. (...) > > ### 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. (...) In the context of doing a release I think we _could_ cut the release branch earlier in the project. Rutherther also brought this up. It's definitely a trade-off. I selected to stay on the master branch for as long as possible because (a) the group has had difficulty with long-running branches, (b) the social signal of doing a release, for a few weeks we all focus on it. I agree we may block up with items to go to master, though given our current velocity a 5 week freeze doesn't seem that big to me. I think that Efraim has an idea that would also try to reduce the freeze time - which I think is along the lines of what you're outlining Ian - Efraim do you want to chime in here? I agree a release branch would also support some form of longer-term stable branch. I don't think doing it that way is a necessary precursor for this GCD, but I do take the point! For now I would keep the idea of maintaining two branches outside the scope of this GCD. > > ### 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? (...) We'd maintain our current approach as we are ultimately a rolling release. My point here was to hold us for a couple of weeks only pushing 'security' issues to the branch, so that the whole of the team can focus on testing the release and fixing release-critical bugs on the 'release' branch. For devs that don't want to focus on the release they can continue to push to their team-branches and/or the "staging" (z572 thinks this sould be called something else). > > ### 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. We already have this problem in the sense that new contributors send contributions against master, and a lot of work is actually against team-branches. For example, people send package updates for rust/python and we already have them in rust-team/python-team branches. I agree it's difficult to manage as it will be a "new thing". > Thank you for starting the discussion! (...) It sounds like you're broadly in favour, but the main improvement would be flipping the branches around. Thanks for the input! Steve / Futurile [0] Ubuntu/Canonical LTS's are always the April release. RedHat is a bit less clear to me, but RHEL 9 was in May, and they've announced that RHEL 10 is mid-2025 so I _think_ they are also on a spring release cycle - https://www.redhat.com/en/blog/red-hat-enterprise-linux-10-beta-now-available - mentions "to release a new major edition every three years .... RHEL 10, due to reach general availability in mid-2025" - https://en.wikipedia.org/wiki/Red_Hat_Enterprise_Linux - RH9 May 2022, RH8 May 2019
