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/ _______________________________________________ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev