[Nix-dev] Stable NixOS releases

Marc Weber marco-oweber at gmx.de
Thu May 16 15:41:24 CEST 2013


Can we talk about the details - how to actually name branches?

I propose having the names:
- "next" receiving tested breaking updates (thus is what is master now)
- "stable" receiving non breaking updates only - this will be aliased to 2013-Q2
- 2013-Q1 receiving non breaking update only
older stable branches (eventually no longer maintained):
2012-Q4

Thus if you subscribe to 2013-Q2 you are stable now, and continue to be
stable for another 3 month which is what you asked for?

The important bit is to understand that stable and "2013-Q2" refer to
the same commits, thus you can follow "stable" or "2013-Q2"
While stable will upgrade every 3 month, 2013-QN will never.

What about nixos vs nixpkgs?

When the branching hell starts, does it make sense to introduce a
nixos/nixpkgs repository whose sole purpose is to to have two
submodules (nixos and nixpkgs), then you could specify versions when
using nixos-rebuild --upgrade or nixos-install this way:

nixos-install  github.com/nixos/nixos-nixpkgs --branch next # current stable, breaking changes should go to next
nixos-install  github.com/nixos/nixos-nixpkgs --branch stable # breaking changes should go to next

The big advantage is that people like me using their own
"haskell-overlays" could simply create their own branch of nixos-nixpkgs
which also checks out haskell & ruby overlays.

So we should consider such a change, too.

I'm in favor of not creating too many rules - we should also adopt to
what changes we are exposed to (eg which kde/gtk/.. updates will happen
etc) - or specifying which packages / test cases belong to a "release"
and must be taken care of. Maybe we can manage to have something like
release.nix to specify this - and treat other packages less seriously.

Marc Weber


More information about the nix-dev mailing list