[Nix-dev] Stable NixOS releases

[Eelco Dolstra]

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.

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/