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