Package updates in 20.03 and stable channels

Hi all, huge Nix fan here and I’m trying to really grasp it. So thanks in advance to all those who contribute to it. I’d like to better understand channel updates. Let me know if this is the right place or not.

I’ve “pinned” to 20.03, but see some packages aggressively update and others are very far behind. Is there a system behind this?

For example, on 20.03, GitHub CLI tool was bumped a few days ago to the very latest 0.8.0. See here:

But on the same release, 20.03, the Google Cloud SDK is lagging months behind.

But on “unstable” both have been updated. So how does the update make it over per package to the “release” branches?

Note that 20.03 was released months after the Google SDK was updated in unstable, so I’m not sure why the release didn’t “capture” these updates. Or why some packages get updated after the release and others don’t (when unstable updates all).

Thanks for any help.

1 Like

The next release is branched off unstable (or master) a while before the actual release to have some time to fix packages that do not build. E.g. 20.03 was branched early February although it was not released until April:

So, a release starts with the versions of unstable at the time of the branch + updates made during the freeze to fix packages + security updates. After the release, updates on a release branch are primarily to fix security issues and/or fix higher-impact bugs/issues (typically things that bother people that put in the time to do a PR and do not have a large impact). When it comes to security issues, sometimes they are fixed by updating to a newer version of a package, sometimes a patch is applied to the existing version.

I don’t know why the GitHub CLI was bumped specifically. Either it addressed a security update, or it was a low-impact version bump that someone wanted or needed and did a PR for.


I think we also keep some end-user software up to date. Ie, I think, for example, VS Code and IntelliJ updates are generally backported.

1 Like

Thanks guys. That’s incredibly helpful. So suffice to say: it’s not an automated process that somehow noticed x.y.z moved to “x.y + 1.z” in the unstable branch and auto updates.

In this case, it is convenient for me that the GitHub CLI was updated (a ton of new features). But I do wonder why. It’s a major release.

Thanks again. This knowledge + declarative channel pinning is a dream come true.

One common exception to the “only bugfixes” rule is software that depends on some external service to work. For example youtube-dl needs to play its cat-and-mouse game with youtube, so keeping an old version on stable would make it essentially useless.

Its possible that this was the reason for the GitHub CLI update. Maybe it was necessary to make it work with the current GitHub server.


@silviogutierrez You might be interested in this section of the cheatsheet (provided you haven’t seen it already) Cheatsheet - NixOS Wiki

It can be useful for low-risk modules with few dependencies.

@mjlbach: thanks. I’ve actually been doing that and I’d say it’s Nix’s #1 killer feature. Interesting you qualify it as for “low-risk, few dependencies” modules. I suppose now that I think about it, with enough groups of channels and packages, eventually this could just blow up with a cryptic error.

Sample of my project setup:

  stableTarball = fetchTarball
  unstableTarball = fetchTarball
  pkgs = import stableTarball { };
  unstable = import unstableTarball { };
in with pkgs; [

  (if stdenv.isDarwin then [
  ] else
    [ ])

  (import ./kubesec.nix)


  (yarn.override { nodejs = nodejs-13_x; })

  # Currently needed only for jarsigner when using a pure shell and building android.

  # Only for nix on docker right now
  # python38Packages.setuptools