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