Why is there no rolling `stable` channel?

You can mix and match stable with unstable Ex.

nix-channel --list
nixos https://nixos.org/channels/nixos-20.09
unstable https://nixos.org/channels/nixos-unstable

In your configuration.nix use below

{ inputs, config, options, pkgs, lib, callPackage, ... }:

let
  unstable = import <unstable> {
    config.allowUnfree = true;
  };
in
{
..
...
    printing = {
      enable = true;
      # drivers = [ unstable.pkgs.epson-escpr ];
      drivers = with pkgs; [ unstable.epson-escpr ];
    };
...
....
 systemPackages = with pkgs; [
      nixpkgs-fmt
      nixpkgs-lint
      nixpkgs-review
      unstable.nix-simple-deploy
      niv
      (lowPrio nix-prefetch-git)
      nix-prefetch-scripts
      unstable.virt-manager
      unstable.virt-viewer
      ...
2 Likes

Allow me to present another usecase for a nixos-stable branch:

At company X, we use flakes. We have a flake template that, among other things, adds a nixpkgs input.

Now, at the moment the template says nixpkgs.url = "github:NixOS/nixpkgs/nixos-22.11", but ideally, it would be something like nixpkgs.url = "github:NixOS/nixpkgs/nixos-stable";.

The reason is that what we use these templates for are not NixOS systems, but packages/containers, and we want users to be able to just do nix flake update at any point, and get the latest stable nixpkgs. Downstream users of these templates don’t want to think about Nix’s release cycle, for them it’s just an irrelevant implementation detail – what they want is stability.

I could go and update the template every 6 months, but that would do nothing for all the instantiations of that template (potentially several dozens), which I would have to go edit individually.

I thought a solution could be to use the implicit nixpkgs input from the system registry, but it seems like this would introduce annoyinggi issues, where nix flake update could produce different results on different machines, depending on whether they pin nixpkgs in their system (or user!) registry, and to what.

(Note that in my usecase, whether a channel is available is irrelevant, as we’re on flakes).

1 Like

If you had such a channel that would always point to the latest stable release in its latest stable version, then your updates would break every 6 months.

If you want to use a stable release, use exactly that stable release, otherwise unstable.

1 Like

Updates wouldn’t happen automatically (there is a human running nix flake update), and they would be gated behind CI infrastructure.

How would they break exactly?

Incompatible version bumps.

Lets say Tool X which you use in version 1 updates to version 2 between 22.11 and 23.05.

Your image, or something within it, relies on the Version 1 calling conventions. But version 2 has different ones.

This is one of the possible problems you might have.

Another problem that might be caused is, that some relevant data storage you maintain via a volume becomes incompatible with the new version.

Not all of the possible problems that can occur can be found by your CI, or require some forethought into the CI to be detectable.

By definition: A rolling release can never be stable as in “there won’t be breaking changes”.

Remember “unstable” does not mean, that your running system will suffer from crashes, it means that each update might have some breaking changes in some dependency.

By pointing at a stable release, you can decide when you want to tackle those potentially incompatible upgrades or if you want to do them at all or just leave the system in the known to work stable release, as a cost analysis has shown, that an update would probably cost more than you would earn by deploying the new version.

Using unstable would give you those problems on an even spread across a release cycle, using your potential “latest-release” alias would slap you straight in the face with all the problems at once exactly 2 times a year.

Usually it is easier to resolve the problems over time as they arise, rather than having to deal with all of the problems at once.

5 Likes