Skip to content

Commit

Permalink
Add option system.stateVersion
Browse files Browse the repository at this point in the history 
This option requests compatibility with older NixOS releases with
respect to stateful data, in cases where new releases have defaults
that might be incompatible with system state of existing NixOS
deployments. For instance, if we change the default version of
PostgreSQL, existing deployments will break if the new version can't
read databases created by the old version.

So for example, setting

  system.stateVersion = "15.07";

requests that options like services.postgresql.package use defaults
corresponding to the 15.07 release branch. Note that
nixos-generate-config emits this option. (In the future, NixOps may
set system.stateVersion to the NixOS release in use when the machine
was created.)

See also #7939 for another motivating example.
  • Loading branch information
@edolstra
edolstra committed Jul 27, 2015
1 parent e3a5bca commit d166c85
Show file tree
Hide file tree
Showing 3 changed files with 28 additions and 2 deletions.
3 changes: 3 additions & 0 deletions nixos/modules/installer/tools/nixos-generate-config.pl
View file
Original file line number Diff line number Diff line change
Expand Up @@ -544,6 +544,9 @@ sub multiLineList {
# uid = 1000;
# };
# The NixOS release to be compatible with for stateful data such as databases.
system.stateVersion = "@nixosRelease@";
}
EOF
} else {
Expand Down
1 change: 1 addition & 0 deletions nixos/modules/installer/tools/tools.nix
View file
Original file line number Diff line number Diff line change
Expand Up @@ -40,6 +40,7 @@ let
src = ./nixos-generate-config.pl;
path = [ pkgs.btrfsProgs ];
perl = "${pkgs.perl}/bin/perl -I${pkgs.perlPackages.FileSlurp}/lib/perl5/site_perl";
inherit (config.system) nixosRelease;
};

nixos-option = makeProg {
Expand Down
26 changes: 24 additions & 2 deletions nixos/modules/misc/version.nix
View file
Original file line number Diff line number Diff line change
Expand Up @@ -6,12 +6,35 @@ with lib;

options = {

system.stateVersion = mkOption {
type = types.str;
default = config.system.nixosRelease;
description = ''
Every once in a while, a new NixOS release may change
configuration defaults in a way incompatible with stateful
data. For instance, if the default version of PostgreSQL
changes, the new version will probably be unable to read your
existing databases. To prevent such breakage, you can set the
value of this option to the NixOS release with which you want
to be compatible. The effect is that NixOS will option
defaults corresponding to the specified release (such as using
an older version of PostgreSQL).
'';
};

system.nixosVersion = mkOption {
internal = true;
type = types.str;
description = "NixOS version.";
};

system.nixosRelease = mkOption {
internal = true;
type = types.str;
default = readFile "${toString pkgs.path}/.version";
description = "NixOS release.";
};

system.nixosVersionSuffix = mkOption {
internal = true;
type = types.str;
Expand Down Expand Up @@ -41,8 +64,7 @@ with lib;

config = {

system.nixosVersion =
mkDefault (readFile "${toString pkgs.path}/.version" + config.system.nixosVersionSuffix);
system.nixosVersion = mkDefault (config.system.nixosRelease + config.system.nixosVersionSuffix);

system.nixosVersionSuffix =
let suffixFile = "${toString pkgs.path}/.version-suffix"; in
Expand Down

8 comments on commit d166c85

@wkennington
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe we shouldn't base this on year.month in case we have slippage like 15.06 -> 15.07? I suppose as long as you don't ever compare to an unreleased version things will stay consistent, it just makes it hard when you are nearing a cut off point if you want to add changes that come after the release.

@edolstra
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What's the alternative?

@bjornfor
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Crazy idea: switch to semantic versioning instead of YEAR.MONTH?

@bjornfor
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Or forget the "semantic" part, just plain integers. Release 1, release 2....

@wkennington
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah I would be okay with an integer that corresponds with the year.month or just switch to integers entirely.
Ex.
13.10 -> 1
14.04 -> 2
14.12 -> 3
15.07 -> 4

@edolstra
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But why, really? This is only a problem if you want to make something conditional on a future release. Which seems a hypothetical problem to me.

@vcunat
Copy link
Member

@vcunat vcunat commented on d166c85 Jul 27, 2015

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Plain integers (incremented whenever we do an incompatible change) are relatively simple/easy, but it isn't obvious to which date was number X changed. YY.MM or YY.MM.DD have the additional advantage that they can be added on the moment the change happens, i.e. if we were doing changes on master now, we could compare to 15.07 regardless of when the real release happens – just signifying the date of introduction on master (which is linearly ordered).

@wkennington
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suppose either way works I just don't really want to commit to something which won't work nicely into the future. If we always use versionOlder / versionAtLeast for all comparisons then we could switch to a plain integer fairly trivially as long as it is larger than the year.

Please sign in to comment.