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.
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
