[Nix-dev] Stable NixOS releases

[Mathijs Kwik]

On Tue, May 14, 2013 at 1:26 PM, Eelco Dolstra
<eelco.dolstra at logicblox.com> wrote:
> Hi all,
>
> I would like to propose making periodic stable releases of NixOS.  Currently we
> only have an "unstable" channel that tracks the master branches of NixOS and
> Nixpkgs.  The fact that these branches receive potentially major changes at
> indeterminate times can make upgrading NixOS somewhat adventurous.  Of course,
> the great thing about NixOS is that recovering from a "bad" upgrade is easy.
> But still, for a production server, you'd rather not run a "nixos-rebuild
> --upgrade" and find that the Linux kernel or PostgreSQL or PHP suddenly changed
> to a different major version.  On the other hand, you do want to get (security)
> bug fixes.
>
> Therefore it would be good to have stable releases that get bug fixes for a
> certain amount of time.  For instance, we could make a stable release every 3
> months or so, named (Ubuntu-style) <year>.<month>, e.g. 13.06, 13.09, and so on.
>
> A release would consist of:
>
> - Archived installation CD images (e.g. unlike the current NixOS ISOs, they
> wouldn't be deleted after a while).
>
> - Likewise, Amazon EC2 AMIs.
>
> - Branches in the NixOS/Nixpkgs GitHub repositories that receive updates to the
> release, e.g. nixos/13.06-release and nixpkgs/13.06-release.
>
> - A channel that tracks the release branches, e.g.
> http://nixos.org/channels/nixos-13.06, just like how the channel
> http://nixos.org/channels/nixos-unstable tracks the master branches.  A system
> installed from a release ISO/AMI would be automatically subscribed to the
> corresponding channel.  Upgrading to a newer release or to the master branch is
> just a matter of running "nix-channel --add http://nixos.org/channels/nixos-...
> nixos && nixos-rebuild ...".
>
> So what kinds of updates would be suitable for release branches?  Typically,
> conservative bug fix releases (e.g. Linux 3.4.45 -> 3.4.46, Firefox 20.0 ->
> 20.0.1), in particular security fixes.

I also think there should be a distinction between "available" and "default".
If our release cycle is more than a couple of weeks, chances are I
want 1 or 2 more recent packages. I don't want to be forced to run
master just because of this.

If a new firefox/kde/kernel comes around, I would like it to be
available in "stable". Of course this means manually
setting/installing an explicit version, so it's clear I have to check
if it works for me. On the next stable upgrade, I have to remove these
overrides to go with the default stable version again.

We can probably achieve this by splitting all-packages.nix into 2
parts. A "pool" with (versioned) packages that follows upstream,
shared between master and stable. And a "pinned" set, containing
overrides to pin specific upstream versions. The end result (pkgs) is
the merge between these 2. As our master is probably tracking upstream
closely, its pinned set is mostly empty.

Example:

the pool contains {
  firefox17 = ...;
  firefox20 = ...; # support drops 05/2013
  firefox21 = ...;

  firefox_lts = firefox17;
  firefox = firefox21;
}

master's pinnedVersions contains {
  # nothing, just following upstram
}

while stable's pinnedVersions has {
  firefox = firefox20;
}

This would mirror the exact upstream situation. The moment firefox20
is no longer supported upstream, it is taken out of the pool. If
"stable" depends on it, it should be clear that something has to be
done. Either pin to firefox_lts, or move the expression to the pinned
set, making clear it is nixos-maintained, not upstream.

I think this layout allows us to track upstream closely, while still
giving what's needed to maintain our own release-cycle. This would
also make it far easier to maintain the nixpkgs stable branch, as it
can just pull master every few days and see if there are overrides
needed. A stable "release" is not much more than emptying
pinnedVersions (apart from a few packages that track some lts by
default in stable).


>
> What shouldn't go into a release branch is major package upgrades that might
> break compatibility (e.g. Linux 3.4 -> 3.9, KDE 4.7 -> 4.10, Mesa 8 -> 9 or
> PostgreSQL 9.2 -> 9.3), or removing or renaming NixOS configuration options.
>
> Adding new packages should be fine.  Adding new (major) versions of packages is
> also fine if they're marked as low-priority and don't change the default version
> of the package (so you can add PostgreSQL 9.3 as long as the default stays 9.2).
>  Likewise, adding NixOS modules is fine as long as they don't enable anything by
> default.  However, I don't anticipate that there would be many of these
> backports, but that depends on interest.
>
> For creating releases, we should have a tracking issue (per release) in GitHub
> that depends on all features scheduled for that release.  These tracking issues
> could also serve as a roadmap for future NixOS development, which we currently
> lack.  For instance, as targets for a hypothetical NixOS 13.06 I would nominate
> (off the top of my head) KDE 4.10, GCC 4.8, and the current x-updates branch.
> (See https://fedoraproject.org/wiki/Releases/19/FeatureList for an example of
> how Fedora does this.)  If a feature is not finished/stable on time, it would
> not go into the release.
>
> I haven't thought very much yet about the actual release process (like "when to
> branch a release off the master").
>
> Comments, ideas, suggestions?
>
> --
> Eelco Dolstra | LogicBlox, Inc. | http://nixos.org/~eelco/
> _______________________________________________
> nix-dev mailing list
> nix-dev at lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev