[Nix-dev] Stable NixOS releases

[Mathijs Kwik]

Eelco Dolstra <eelco.dolstra at logicblox.com> writes:

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

Wow, (y)our little distro is growing up so fast :')
Congrats on reaching the point where the user base has become large enough
and is running serious production stuff on it, mandating a stable
channel.

I would prefer a 3 months cycle.
6 months is quite long, making upgrades (possibly) harder to do.
Also, we probably want releases to be backward compatible 1 release
(regarding configuration.nix and nix features), so a long cycle might
complicate things or hold back master development.

Also, I'm against these extremely-managed/planned bureaucratic projects,
with a feature freeze and various beta/RC phases that affect what you
can and cannot do on master.

I think the process should be very simple:
- You send out an email saying "it's release time again"
- People nominate a git revision that's at least 1 week old so it has
  been tested a little bit.
- this revision becomes stable-RC
- we decide if RC is good enough or whether small things need to be
  fixed/cherry-picked
- merge stable-RC into stable

Preferably the whole process takes at most 4 or 5 days.
Announcement on wednesday, release on monday. This makes the weekend
into a nice community-hackathon :) That way, maintainers/users will
probably invest some time to test/fix things.
If the timeframe is 2 or 3 weeks, people might get sloppy and postpone
testing it out and collaborating.

But that's just my thought and I'm in no way good at releasing and
deadlines and stuff like that :P
So I'm interested in what others would do.

Mathijs