2021-05-19

<dminuoso> refusing to bump stateVersion will keep your default database version old
<dminuoso> so one motivating reason to bump stateVersion is if you want a newer postgres (default) version
<srhb> rauno: That is essentially the purpose of stateVersion
<srhb> rauno: A simple example for what it might be used for: Say service Foo has a datadir /var/Foo. Someone decides to change it in 21.05 to be /var/lib/Foo, but gates it behind stateVersion >= 21.05. If you were to change your stateVersion willy nilly to 21.05, this compatibility safety would go out the window and your service Foo would start with the new datadir, where none of its data lives.
<rauno> Okay. So when everything works and is upgraded, then i can finally change the stateVersion after reboot ?
<rauno> Whats the logic behind stateVersion? When it should be upgraded ?
<rauno> So i just upgrade the nixpkgs repo and keep stateVersion 18.09 ?
<dminuoso> rauno: sure, just remember to keep stateVersion the same

2021-05-16

<{^_^}> Special commands: find tell locate expand inclusive-language random-pr permalink - Commands sorted by use count, page 0 (use ,<n> to view page <n>): help channels ping libraries -a escape'' botsnack escape" library ifd pinning overlay unfree which-channel imperative xy xml wololo fancy-uninstall nixlang++ unstable commands home-manager pointers cache thesis pills runtimedeps stateversion invite exec smart-questions howoldis callpackage dnw paste
<legendofmiracles> ,stateversion
<{^_^}> Changing stateVersion doesn't upgrade anything and can only break your setup at best. To actually upgrade NixOS see https://nixos.org/nixos/manual/#sec-upgrading. If you need to change stateVersion for some odd reason regardless, Ctrl-F for "stateVersion" in https://nixos.org/nixos/manual/release-notes.html to see things that need to be manually migrated with the new value
<{^_^}> Special commands: find tell locate expand inclusive-language random-pr permalink - Commands sorted by use count, page 0 (use ,<n> to view page <n>): help channels ping libraries -a escape'' escape" library botsnack ifd pinning overlay unfree which-channel imperative xml xy wololo fancy-uninstall nixlang++ unstable commands home-manager pointers cache thesis pills runtimedeps invite stateversion exec smart-questions howoldis callpackage dnw paste

2021-04-26

<srhb> turlando: Yes (that is the purpose of stateVersion) :)
<turlando> srhb yep, I mean nixos. So without touching stateVersion I should be able to upgrade seamlessly?
<srhb> turlando: I would not recommend to stick on "20.03" if you mean NixOS itself (_not_ stateVersion) :)
<cransom> though, i did some work this weekend on a machine that had an 18.09 stateVersion and i updated it because of an internal OCD.
<srhb> turlando: Essentially before changing it, you'd have to take manual steps to upgrade all stateful data, which is not trivial. In fact I'd probably rather do a backup-reinstall-restore than bump my stateVersion :P
<cransom> stateVersion is a compatability level setting. if you have stateversion 20.03, and there was a change for a module you use, in order to not break your system when using 20.09, the 20.09 module will adjust itself to be compatible with 20.03.
<srhb> turlando: I don't remember if nix-channel --add overwrites the same-named channel or not. If it does you're good, if not, delete the old one and create the new one. I don't know where the stateVersion comment is coming from, can you link it? Normally you should _not_ alter stateVersion during an upgrade.
<turlando> I'm doing my first upgrade from nixos 20.03 to 20.09. I've read the documentation and I should just run nix-channel --add https://nixos.org/channels/nixos-20.09 nixos as root. Should I remove the old channel afterwards or nix will take care of that? I'm reading the faq about when updating stateVersion: what does it mean «2. You have verified all instances of stateVersion in the code in <nixpkgs/nixos>.»?

2021-03-08

<etu> karantan: As long as you don't touch stateVersion it shouldn't be a problem, but I would still have a backup of things are important

2021-02-13

<adisbladis> I was under the impression that your stateVersion was set to 20.09 in your expression, but ended up at 21.03 in the deployment
<adisbladis> aleph-: The only thing that comes to mind is the stateVersion thing
<aleph-> adisbladis: So I didn't modify stateversion in my config.nix for the host. Nix channels are: https://paste.rs/Z70

2021-02-08

<{^_^}> Special commands: find tell locate expand inclusive-language random-pr permalink - Commands sorted by use count, page 0 (use ,<n> to view page <n>): help channels ping libraries -a escape'' escape" library ifd botsnack pinning ask overlay unfree tofu which-channel imperative xml xy launch wololo fancy-uninstall nixlang++ commands pointers cache home-manager thesis unstable pills runtimedeps stateversion invite exec smart-questions dnw howoldis

2021-02-04

<dminuoso> Seems like this should have been pinned to stateVersion?

2021-01-26

<__monty__> mgsk: You didn't mess with stateVersion, right?

2021-01-24

<JaakkoLuttinen[m> Can I somehow see what is the current `stateVersion` in use in my running system? I don't have it specified at the moment in `configuration.nix` so I'd like to set it but so that it's the same that my system is currently using.

2021-01-18

<{^_^}> Special commands: find tell locate expand inclusive-language random-pr permalink - Commands sorted by use count, page 0 (use ,<n> to view page <n>): help channels ping libraries escape'' -a escape" library ifd botsnack overlay pinning ask unfree which-channel imperative tofu xml xy wololo fancy-uninstall nixlang++ pointers cache commands home-manager pills runtimedeps thesis stateversion invite unstable exec smart-questions dnw matrixbridge tias

2021-01-13

<hlavaty> postgres in nixos2009 does not respect stateVersion and more anoyingly sets superUser option as readonly. Is there a workaround to fix that?

2021-01-12

<ZaraChimera> I have left my stateVersion as is. I didn't realize that I don't need a nixos-20.09 in both sudo and user.
<{^_^}> Changing stateVersion doesn't upgrade anything and can only break your setup at best. To actually upgrade NixOS see https://nixos.org/nixos/manual/#sec-upgrading. If you need to change stateVersion for some odd reason regardless, Ctrl-F for "stateVersion" in https://nixos.org/nixos/manual/release-notes.html to see things that need to be manually migrated with the new value
<clever> ,stateVersion

2020-12-28

<clever> nlyy: dont change stateVersion

2020-12-20

<duairc> I don't think it's new. The default value of home.stateVersion is 18.09, and the default value of programs.firefox.package looks at the stateVersion to decide if it should be a pkgs.firefox or pkgs.firefox-wrapped

2020-12-16

<infinisil> An error would show why it's needed, and what the latest stateVersion is
<infinisil> If I had enough motivation I'd do an rfc for making stateVersion per-module though :)
<gchristensen> infinisil: not conceptually, it sounds like codygman thinks their stateversion needs "fixing"
<infinisil> gchristensen: The main problem is that there's a single stateVersion for all modules
<colemickens> It seems like maybe you removed the stateversion that was generated when you installed?
<adisbladis> There is nothing wrong with the stateVersion
<adisbladis> When you did `nixos-generate-config` a stateVersion was pinned
<adisbladis> codygman: The stateVersion is fixed at config generation time
<colemickens> codygman: the point is that stateVersion is independent from the nixpkgs version.
<colemickens> So, Jellyfin, for example, had a majorly breaking change in it's latest version, so much so that you may be "stuck" with the old version of Jellyfin according ot your stateVersion.
<colemickens> codygman: stateVersion is used to get backward incompatible changes
<colemickens> codygman: no, stateVersion is important stil
<adisbladis> codygman__: Because your stateVersion does not indicate what version of nixpkgs you're using

2020-12-15

<{^_^}> Special commands: find tell locate expand inclusive-language random-pr permalink - Commands sorted by use count, page 0 (use ,<n> to view page <n>): help libraries channels ping paste escape'' -a escape" library ifd overlay botsnack pinning profiling unfree ask which-channel imperative xml wololo xy fancy-uninstall tofu nixlang++ pointers cache commands pills runtimedeps thesis home-manager invite stateversion unstable exec smart-questions

2020-12-09

<tejing> my stateVersion is ancient
<tejing> could stateVersion affect that? I would guess no, but that's my only guess left

2020-11-30

<Alastair> Ok. Well I tried with `stateVersion = 19.09` and no luck

2020-11-28

<infinisil> kyren: If postgresql is the only thing requiring manual migration, you should be able to update stateVersion after having done that

2020-11-08

<__monty__> Is the default configuration nixos generates (or nixos-install I guess?) in the nixpkgs repo somewhere? I'm looking for the stateVersion comment.

2020-11-03

<{^_^}> Special commands: find tell locate expand inclusive-language random-pr - Commands sorted by use count, page 0 (use ,<n> to view page <n>): help libraries ping channels paste escape'' -a escape" library overlay ifd pinning botsnack profiling unfree ask which-channel xml xy fancy-uninstall imperative wololo nixlang++ tofu cache pills pointers home-manager invite runtimedeps stateversion thesis commands exec matrixbridge smart-questions tias

2020-10-27

<jdnixx[m]> and btw what does the stateVersion actually do at all then, if anything

2020-10-26

<cole-h> And prepend `stateVersion` with `home.`

2020-10-19

<{^_^}> Special commands: find tell locate expand inclusive-language random-pr - Commands sorted by use count, page 0 (use ,<n> to view page <n>): help libraries channels paste ping escape'' escape" -a library overlay ifd pinning profiling unfree botsnack ask which-channel xml xy fancy-uninstall imperative wololo nixlang++ cache pills pointers home-manager invite runtimedeps stateversion thesis tofu commands matrixbridge exec smart-questions configsearch

2020-10-16

<lordcirth> notgne2, you mean overriding stateVersion?

2020-10-03

<pickfire> Oh, what's the point of stateVersion there though haha.
<{^_^}> Changing stateVersion doesn't upgrade anything and can only break your setup at best. To actually upgrade NixOS see https://nixos.org/nixos/manual/#sec-upgrading. If you need to change stateVersion for some odd reason regardless, Ctrl-F for "stateVersion" in https://nixos.org/nixos/manual/release-notes.html to see things that need to be manually migrated with the new value
<simpson> ,stateVersion

2020-09-17

<tobiasBora> jumper149: what's the issue? Too old? If may come from the fact that you have a stateVersion with old values.

2020-09-15

<{^_^}> Special commands: find tell locate expand inclusive-language random-pr - Commands sorted by use count, page 0 (use ,<n> to view page <n>): help libraries paste channels ping escape'' escape" -a library overlay pinning ifd profiling unfree ask botsnack which-channel xml xy fancy-uninstall wololo imperative nixlang++ cache pointers pills invite runtimedeps home-manager stateversion thesis exec matrixbridge smart-questions dnw howoldis commands tias

2020-09-10

<Ke> stateVersion manages some incompatibilities and maybe migrations, I believe, never had to use it myself

2020-09-09

<{^_^}> [nixpkgs] @worldofpeace merged pull request #95987 → nixos/jellyfin: document stateVersion 20.09 in release notes → https://git.io/JUv3F

2020-09-04

<dminuoso> There's no inherent version inside nixpkgs, apart from the few things relying on stateVersion
<samueldr> but if you're sharing the config, like through a common git config, make sure that your new computer and your older computer have distinct ways to define their own stateVersion values
<samueldr> the stateVersion variable is used to tell some parts of the nixos configuration that the state saved comes from an older setup
<iqubic> However that particular configuration.nix that I copied from my old laptop has has the stateVersion set to 17.03.

2020-09-03

<clever> so you need to be aware of those changes, and manually migrate the state before you change the stateVersion
<clever> inkbottle: thats what stateVersion is for, to minimize the breakage when you upgrade without reading the release notes
<iqubic> I've done plenty of NixOS installs in the past. It usually consists of copying over my current configuration.nix, updating the stateVersion, and generating a new hardware-configuration.nix
<samueldr> tobiasBora0: you could put back the same stateVersion that you had, since you're putting back the same state
<tobiasBora0> ok cool, I was just affraid that stateVersion changes could break some stuff, I'll try and see if it works. Thanks!

2020-08-22

<{^_^}> [nixpkgs] @minijackson opened pull request #95987 → nixos/jellyfin: document stateVersion 20.09 in release notes → https://git.io/JUv3F
<infinisil> Hm though I'm just noticing that it doesn't set stateVersion

2020-08-20

<{^_^}> Special commands: find tell locate expand inclusive-language random-pr - Commands sorted by use count, page 0 (use ,<n> to view page <n>): help libraries paste escape'' ping channels escape" -a library overlay pinning ifd profiling unfree ask botsnack which-channel xml xy fancy-uninstall imperative nixlang++ wololo cache pointers pills invite runtimedeps home-manager stateversion thesis exec matrixbridge smart-questions howoldis -ia configsearch

2020-08-05

<{^_^}> Special commands: find tell locate expand inclusive-language random-pr - Commands sorted by use count, page 0 (use ,<n> to view page <n>): help unstable libraries tofu paste escape'' escape" ping -a library channels overlay ifd pinning unfree profiling ask botsnack which-channel xml pr tofu-vim xy fancy-uninstall imperative wololo nixlang++ cache pointers pills invite runtimedeps home-manager stateversion thesis exec matrixbridge smart-questions
<{^_^}> Special commands: find tell locate expand inclusive-language random-pr - Commands sorted by use count, page 0 (use ,<n> to view page <n>): help libraries unstable tofu paste escape'' escape" ping -a library channels overlay ifd pinning unfree profiling ask botsnack which-channel xml pr tofu-vim xy fancy-uninstall imperative wololo nixlang++ cache pointers pills invite runtimedeps home-manager stateversion thesis exec matrixbridge smart-questions

2020-08-04

<{^_^}> [nixpkgs] @edolstra closed pull request #35366 → nixos: properly disable sound by default, if stateVersion > 18.03 → https://git.io/vAgpa
<clever> thats what the stateVersion stuff is for, so it wont change when you upgrade nixpkgs
<clever> Alling: there is a services.postgresql.superUser option, and the default varies, based on stateVersion
<Alling> Should I make sure my system has a `postgres` user if I want to use Postgres with `stateVersion: "20.03"`?
<srhb> frodo: However, stateVersion and nixpkgs version are uncoupled, (hence the important comment)

2020-07-31

<{^_^}> Special commands: find tell locate expand inclusive-language random-pr - Commands sorted by use count, page 0 (use ,<n> to view page <n>): help libraries unstable tofu paste escape'' escape" ping -a library overlay channels pinning ifd unfree profiling ask botsnack which-channel pr tofu-vim xml xy fancy-uninstall imperative wololo nixlang++ cache pointers pills invite runtimedeps home-manager stateversion matrixbridge smart-questions thesis exec

2020-07-17

<veleiro> maybe i'm not understanding how these stateversions work with persistence

2020-07-01

<notgne2> so instead of `postgresql = super.postgresql_11.overrideAttrs (old: {` you would need `postgresql_11 = super.postgresql_11.overrideAttrs (old: {` or whatever version you are trying to alter, and if you don't intend on using the default version for your system stateVersion then be sure to explicitly set it too (if you have an overlay altering `postgresql_11` you can just do `.package =
<notgne2> so for example if your stateVersion is 20.03 it will use a package called `postgresql_11`, so thats what you would need to override

2020-06-25

<{^_^}> Special commands: find tell locate expand inclusive-language random-pr - Commands sorted by use count, page 0 (use ,<n> to view page <n>): help unstable libraries paste escape'' tofu declarative escape" library overlay ping -a pinning ifd unfree profiling ask botsnack which-channel channels xml pr tofu-vim xy wololo fancy-uninstall imperative nixlang++ cache pointers invite pills runtimedeps stateversion home-manager matrixbridge smart-questions

2020-06-12

<tobiasBora> Ok great, I managed to get gitea to work again with a proper system.stateVersion = "18.09";! Now, my question is: if I don't want to keep old softwares (like postgresql 9.6 in that case) is there some script that can automatically moves me from one stateVersion to another stateVersion?

2020-06-10

<dramforever> It's using a configuration I had for a while (stateVersion is 18.09) and I'm running it on nixos-unstable. I found some stuff about glibc incompatibilities but I can't see why it could apply

2020-06-09

<{^_^}> Special commands: find tell locate expand inclusive-language random-pr - Commands sorted by use count, page 0 (use ,<n> to view page <n>): help libraries unstable escape'' paste declarative escape" tofu library overlay ping -a pinning unfree ifd profiling ask botsnack which-channel xml pr xy tofu-vim wololo imperative nixlang++ cache fancy-uninstall pointers invite pills stateversion home-manager runtimedeps matrixbridge channels thesis exec

2020-05-19

<{^_^}> Changing stateVersion doesn't upgrade anything and can only break your setup at best. To actually upgrade NixOS see https://nixos.org/nixos/manual/#sec-upgrading. If you need to change stateVersion for some odd reason regardless, Ctrl-F for "stateVersion" in https://nixos.org/nixos/manual/release-notes.html to see things that need to be manually migrated with the new value
<b42> ,stateVersion
<clever> typetetris: the first time nixops deploys, it will query the remote machine for its stateVersion, and then put that into the internal sqlite database

2020-05-17

<quinn> for posterity: bumped stateVersion 19.03 -> 20.03, systemctl --failed is empty
<quinn> i am looking to bump my stateVersion, and per the release notes of for 19.09, apparently i need to be on stateVersion 19.03 to keep timesyncd working? is there any way i can fix this?

2020-05-11

<{^_^}> amanjeev: Changing stateVersion doesn't upgrade anything and can only break your setup at best. To actually upgrade NixOS see https://nixos.org/nixos/manual/#sec-upgrading. If you need to change stateVersion for some odd reason regardless, Ctrl-F for "stateVersion" in https://nixos.org/nixos/manual/release-notes.html to see things that need to be manually migrated with the new value
<qyliss> ,stateVersion amanjeev

2020-05-10

<{^_^}> EdLin: Changing stateVersion doesn't upgrade anything and can only break your setup at best. To actually upgrade NixOS see https://nixos.org/nixos/manual/#sec-upgrading. If you need to change stateVersion for some odd reason regardless, Ctrl-F for "stateVersion" in https://nixos.org/nixos/manual/release-notes.html to see things that need to be manually migrated with the new value
<clever> ,stateVersion EdLin

2020-05-04

<maralorn> keithy: In general you should re set the stateVersion to what it was before. It is not supposed to be changed. It is a way for nixos to with which configuration you installed nixos so that it does not break your stateful data on disk.
<lassulus> stateVersion is not meant to be changed

2020-04-29

<LnL> evanjs: careful, stateVersion is for compatibility has nothing to do with your channel
<evanjs> Ohhh good call, I need to update my stateVersions... I think?

2020-04-27

<immae> In any case, just changing the stateVersion and rebuilding should tell you everything that would change
<immae> Yes that’s it, I know that stateVersion affects postgres and when I read about the upgrade I "knew" it was that, but it’s not obvious as said in the release note

2020-04-26

<tobeportable> "Changing stateVersion doesn't upgrade anything and can only break your setup at best" -> should I revert back to 19.09 if modified it already ?
<infinisil> ,stateVersion
<{^_^}> Changing stateVersion doesn't upgrade anything and can only break your setup at best. To actually upgrade NixOS see https://nixos.org/nixos/manual/#sec-upgrading. If you need to change stateVersion for some odd reason regardless, Ctrl-F for "stateVersion" in https://nixos.org/nixos/manual/release-notes.html to see things that need to be manually migrated with the new value

2020-04-18

<{^_^}> Changing stateVersion doesn't upgrade anything and can only break your setup at best. To actually upgrade NixOS see https://nixos.org/nixos/manual/#sec-upgrading. If you need to change stateVersion for some odd reason regardless, Ctrl-F for "stateVersion" in https://nixos.org/nixos/manual/release-notes.html to see things that need to be manually migrated with the new value
<cole-h> ,stateversion

2020-04-15

<clever> and its using stateVersion to figure out if you installed before or after, and keep it from changing and breaking

2020-04-12

<clever> monokrome: the idea, is that you manually fix those things, before you upgrade the stateVersion
<energizer> monokrome: you just want to find out what the current stateVersion is?

2020-04-10

<Guest1> yeah, i dont know exactly what problem stateVersion solves, but i believe my flash drive has the same version as this install
<thibm> (The stateVersion misunderstanding is really a thing…)
<nschoe> What/who uses this stateVersion then?

2020-04-08

<gchristensen> ,stateversion
<{^_^}> Changing stateVersion doesn't upgrade anything and can only break your setup at best. To actually upgrade NixOS see https://nixos.org/nixos/manual/#sec-upgrading. If you need to change stateVersion for some odd reason regardless, Ctrl-F for "stateVersion" in https://nixos.org/nixos/manual/release-notes.html to see things that need to be manually migrated with the new value

2020-04-04

<{^_^}> sullyj3: Changing stateVersion doesn't upgrade anything and can only break your setup at best. To actually upgrade NixOS see https://nixos.org/nixos/manual/#sec-upgrading. If you need to change stateVersion for some odd reason regardless, Ctrl-F for "stateVersion" in https://nixos.org/nixos/manual/release-notes.html to see things that need to be manually migrated with the new value
<clever> ,stateVersion sullyj3
<clever> sullyj3: the stateVersion means nothing

2020-03-29

<worldofpeace> DigitalKiwi: lol, but that means unstable since there's no unstable stateVersion we could match against and just use the release number

2020-03-28

<worldofpeace> jlv: xterm used to be a default desktop manager... for some unknown reason. and somehow things relied on it, so via the release note and the stateVersion (to not break existing users setup's) we'd allow some sort of migration
<worldofpeace> jlv: they must have different stateVersion's

2020-03-22

<xfix> stateVersion should not change after installing NixOS
<xfix> changing the stateVersion from 17.03 would result in breakage
<xfix> the idea of stateVersion is to allow changing defaults without breaking it for upgrades from older NixOS versions
<xfix> in general, you don't want to modify stateVersion
<samueldr> stateVersion could be better named "whenWasThisInstallationFirstSetupSoWeCanFindTheFilesAtTheRightPlace"
<samueldr> evils: anyway a user should not change stateVersion, so what would happen when tuptime changes it schema? user will be forced to change it? two distinct versions would be maintained%?
<evils> i'm packaging tuptime, which keeps a database and sometimes changes its format, should i do something with stateVersion now, or only deal with that if they change their format again?

2020-03-21

<{^_^}> fusion809: Changing stateVersion doesn't upgrade anything and can only break your setup at best. To actually upgrade NixOS see https://nixos.org/nixos/manual/#sec-upgrading. If you need to change stateVersion for some odd reason regardless, Ctrl-F for "stateVersion" in https://nixos.org/nixos/manual/release-notes.html to see things that need to be manually migrated with the new value
<clever> ,stateVersion fusion809
<colemickens> The stateversion does not have anything to do with teh version of packages you get.

2020-03-11

<tomturbo> hello, I'm trying to manage my xmonad configuration in nixos via "services.xserver.windowManager.xmonad.config". I'm doing this on another machine, so I know that it should work. On this machine however, the key "config" does not exist. I've also confirmed this via the repl. According to the options online, the key should exist however. My stateVersion is 19.09 (same on the machine it works on) and I've
<clever> adisbladis: that just leaves stateVersion then
<clever> adisbladis: first, nixops will query the stateVersion, and remember it in the state file

2020-03-08

<ottidmes> tokudan: maybe stateVersion related? maybe check the readme of 20.03 if available?

2020-02-26

<{^_^}> [nixpkgs] @tilpner closed pull request #80907 → nixos/version: obfuscate stateVersion to discourage modification → https://git.io/Jv079

2020-02-23

<{^_^}> [nixpkgs] @tilpner opened pull request #80907 → nixos/version: obfuscate stateVersion to discourage modification → https://git.io/Jv079
<__monty__> tilpner: Yeah but if it's already been deployed you can technically figure out the stateVersion by looking at the db.
<__monty__> tilpner: NixOps can't deploy configurations with a newer stateVersion?
<tilpner> And I can only do that, because stateVersion of the evaluated system does not depend on some global state on my laptop
<__monty__> tilpner: Otoh, it doesn't really make sense to evaluate a config with an old StateVersion on a fresh machine...
<GiGa> I was never sure what stateVersion was for, was just aware that I was to leave it alone. I should look up what it actually does...
<tilpner> And we can also make stateVersion an internal option and set it from a better-named option
<__monty__> tilpner: Not necessarily, you can have stateVersion = newBetterName.
<fendor_> why does timesync depend on stateVersion?
<tilpner> That's it, I'll send a PR that encodes stateVersion
<fendor_> tilpner, changing stateVersion to "19.03", followed by `nixos-rebuild switch` succeeded
<fendor_> tilpner, Probably misinterpreted the comment regarding stateVersion, then
<tilpner> fendor_: Is there a stateVersion in your configuration.nix, and did you touch it?

2020-02-19

<itiscoldhere> infinisil: thank you for your quick response. I'll read in the manual for "stateVersion", very helpful
<{^_^}> itiscoldhere: Changing stateVersion doesn't upgrade anything and can only break your setup at best. To actually upgrade NixOS see https://nixos.org/nixos/manual/#sec-upgrading. If you need to change stateVersion for some odd reason regardless, Ctrl-F for "stateVersion" in https://nixos.org/nixos/manual/release-notes.html to see things that need to be manually migrated with the new value
<infinisil> ,stateVersion itiscoldhere

2020-02-14

<{^_^}> stateversion redefined, was defined as Setting stateVersion to the latest release doesn't upgrade anything and can only break your setup at best. To actually upgrade NixOS see https://nixos.org/nixos/manual/#sec-upgrading. If you want to update the stateVersion option regardless, Ctrl-F for "stateVersion" in https://nixos.org/nixos/manual/release-notes.html to see things that need to be manually migrated with the new value.
<infinisil> ,stateVersion = Setting stateVersion to the latest release doesn't upgrade anything and can only break your setup at best. To actually upgrade NixOS see https://nixos.org/nixos/manual/#sec-upgrading. If you need to update the stateVersion option for some odd reason regardless, Ctrl-F for "stateVersion" in https://nixos.org/nixos/manual/release-notes.html to see things that need to be manually
<{^_^}> eoli3n: Setting stateVersion to the latest release doesn't upgrade anything and can only break your setup at best. To actually upgrade NixOS see https://nixos.org/nixos/manual/#sec-upgrading. If you want to update the stateVersion option regardless, Ctrl-F for "stateVersion" in https://nixos.org/nixos/manual/release-notes.html to see things that need to be manually migrated with the new value.
<infinisil> ,stateVersion eoli3n

2020-01-30

<{^_^}> Special commands: find tell locate expand inclusive-language random-pr - Commands sorted by use count, page 0 (use ,<n> to view page <n>): help libraries unstable escape'' declarative library howoldis paste unfree escape" ping callpackage pinning -a profiling ask overlay stateversion pr which-channel tofu xml nixlang++ ifd wololo botsnack channels cache fancy-uninstall invite xy exec imperative pills haskell loot home-manager pointers random-pr

2020-01-20

<srhb> stateVersion should only be carefully changed once you've read necessary migration steps and either concluded that there are none for the modules you use, or you've taken manual steps to do the bump.
<srhb> This should not matter in general, nor should you ever update your stateVersion just like that :)
<lovesegfault> Always keep the stateVersion at the latest stable, despite being on unstable; it's the secret to a happy life
<etu> In general it's not recommended to bump stateVersion

2020-01-13

<{^_^}> rmra: Setting stateVersion to the latest release doesn't upgrade anything and can only break your setup at best. To actually upgrade NixOS see https://nixos.org/nixos/manual/#sec-upgrading. If you want to update the stateVersion option regardless, Ctrl-F for "stateVersion" in https://nixos.org/nixos/manual/release-notes.html to see things that need to be manually migrated with the new value.
<infinisil> ,stateVersion rmra
<infinisil> rmra: You probably updated stateVersion in your configuration.nix. Don't do that, revert it to the previous value
<{^_^}> Special commands: find tell locate expand guys - Commands sorted by use count, page 0 (use ,<n> to view page <n>): help libraries unstable escape'' declarative library howoldis paste unfree ping -a escape" pinning profiling callpackage ask overlay pr stateversion which-channel xml ifd nixlang++ wololo botsnack channels tofu cache xy exec imperative fancy-uninstall invite pills dnw haskell loot home-manager matrixbridge pointers configsearch

2020-01-10

<{^_^}> [nixpkgs] @nh2 merged pull request #77279 → Improve documentation for stateVersion → https://git.io/JvenY

2020-01-08

<{^_^}> #77279 (by maralorn, 19 hours ago, open): Improve documentation for stateVersion

2020-01-07

<{^_^}> [nixpkgs] @maralorn opened pull request #77279 → Improve documentation for stateVersion → https://git.io/JvenY
<infinisil> maralorn[m]: In my vision, stateVersion can be automatically migrated. E.g. where each version bump for each module includes a script to run
<maralorn[m]> If would kind of be a checklist of what I need to migrate if I want to bump the stateVersion.
<maralorn[m]> infinisil: Which is exactly my point. It would be very easy to find all mentions of stateVersion in nixpkgs. But I want explicitly all the places where my specific system is affected by it.
<kqb> So $ man -K 'appstream' seems to have found configuration.nix . Running $ man -K 'stateVersion' found a useful configuration.nix man page. Side note: there are also hints at services.radicale.package or services.redmine.package exhibiting different behaviour depending system.stateVerion; just to have two concrete examples.
<maralorn[m]> I think it would be marvelous to have a tool which could tell you which values in the configuration of a specific system are affected by a set stateVersion.
<kqb> Hopefully better: $ man --global-apropos 'stateVersion'
<kqb> maralorn[m]: On my system where I just switched the channel and ran ... --upgrade , I could not find "stateVersion" in man configuration.nix . I was also unaware up to now that the information from the man pages was called the option documentation.
<kqb> choose a version based off your stateVersion so you don't have
<kqb> The attribute stateVersion is a promise to the NixOS modules
<kqb> <notgne2> it won't actually overlay any packages, just means the postgresql service for instance will automatically choose a version based off your stateVersion so you don't have to manually pin the version to avoid things breaking
<kqb> stateVersion is a promise to the NixOS modules that the state it can't look at really was created with a nixpkgs version from that time
<maralorn[m]> The problem with a non global stateVersion is (I guess) that a module might not know in advance that it will later need a stateVersion. So then at the point where they introduce one they need it to default to the old state for it to make any sense.
<infinisil> notgne2: But yeah if an incompatibility is found, it could be an assertion doing `if bar is enabled, foo's stateVersion needs to be > 1`
<infinisil> notgne2: Can't rely on it though, people can still set per-module stateVersions themselves
<notgne2> the current global stateVersion is turned into package versions, it could just as easily be turned into module specific stateVersions, something like `if config.stateVersion == "19.03" then 3 else 5` inside the module itself
<infinisil> notgne2: Scenario: The default stateVersion for foo is 0 and for bar it's 1, what should the global default be? Now foo gets changed twice, its default stateVersion should now be 2, while bar's is still 1, what should the global default be now?
<notgne2> infinisil: that could still be derived in some way from the nixos version global stateversion
<kqb> How many packages / modules are currently affected by stateVersion? How can I query this information?
<notgne2> I don't think it's that bad of a cost, but imo it's more for users to worry about unnecesarily when it could be avoided by having a global stateVersion that the per-module stateVersions can default to
<infinisil> kqb: kapil_: Another problem with the global stateVersion is that you can't just update the stateVersion for one module, you have to do them all at once, whereas with modular ones you can do it for each service separately
<kqb> infinisil: I am also unsure whether the proliferation of stateVersion attributes is a good idea from the current standpoint.
<infinisil> notgne2: Currently only very little modules need a stateVersion, it would just be another option among the others, like `options.services.postgresql.stateVersion = mkStateVersionOption { ... }`
<infinisil> notgne2: Also, people won't need to set stateVersion anymore unless they use a module which needs it (with per-module state version)
<kqb> At least for me, the comment in configuration.nix was not enough to communicate, that there is seldom a *realistic* reason to touch stateVersion.
<infinisil> kqb: The advantage would be that we won't have to rely on users setting the correct stateVersion, though then it's not easily changeable either which can be problematic
<notgne2> my personal opinion on stateVersion would be to keep it as a config property, but additionally have config properties per-module
<kqb> How about adding "`stateVersion` is a promise to the NixOS modules that the state it can't look at really was created with a nixpkgs version from that time." to the documentation for the option at https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/misc/version.nix and adding a "See also https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/misc/version.nix" to the documentation in the configuration.nix file at https://github.com/NixOS/
<notgne2> it won't actually overlay any packages, just means the postgresql service for instance will automatically choose a version based off your stateVersion so you don't have to manually pin the version to avoid things breaking
<tilpner> Yes, stateVersion is a promise to the NixOS modules that the state it can't look at really was created with a nixpkgs version from that time
<notgne2> stateVersion is only really read by modules which enable software to write stuff to /var
<kqb> I think I understand the store. But it seems to me that the state that is communicated to nixos through stateVersion is *not* in the nix store.
<notgne2> you can either override it, or it will be chosed based off stateVersion
<kqb> So how does nix decide whether to use the default postgres pinned by stateVersion instead of another postgres version I installed in parallel?
<maralorn[m]> With e.g. postgres the database software used will either be hardcoded by the admin or it will default to the postgres which was stable at the specified stateVersion.
<maralorn[m]> kqb: But stateVersion is used for different purposes.
<maralorn[m]> kqb: The documentation for this is primarily the comment above stateVersion in the generated configuration.nix.
<tilpner> kqb: The key here is "When upgrading from ...". It's not saying that stateVersion always needs to be <=19.03
<kqb> Where is documentation on that? If I do a text search for "stateVersion" on https://nixos.org/nixos/manual/ I get no hits.
<kqb> tilpner: I suspect my last message is easy to misunderstand. Let me rephrase: The release notes mention that for timesyncd to work, stateVersion must be 19.03 or *older*. If stateVersion is newer than 19.03, say 19.09, then timesyncd will break.
<tilpner> kqb: I don't think timesyncd is generally broken, just if stateVersion was changed
<kqb> tilpner: *facepalm* thank you for pointing out Ctrl-F. I had not thought of doing a text search on the release notes. It turns out that timesyncd has trouble with stateVersion > 19.03 . I will try another ntp solution from https://nixos.wiki/wiki/NTP.
<{^_^}> kqb: Setting stateVersion to the latest release doesn't upgrade anything and can only break your setup at best. To actually upgrade NixOS see https://nixos.org/nixos/manual/#sec-upgrading. If you want to update the stateVersion option regardless, Ctrl-F for "stateVersion" in https://nixos.org/nixos/manual/release-notes.html to see things that need to be manually migrated with the new value.
<tilpner> ,stateVersion kqb
<tilpner> kbz: Did you "upgrade" by changing stateVersion?
<kqb> clever: I think I phrased my question badly. Is it just that every bit of state that my machine tracks as its job that is not in the Nix store or NixOS modules (configuration.nix, etc.) is something I have to watch out for in general and stateVersion is there for helping me communicate to NixOS where to be careful about things it cannot see?
<clever> kqb: when you want to migrate your state to the newer stateVersion, and deal with whatever changes happened
<clever> kqb: ideally, you would leave stateVersion unchanged, and only use nix-channel to update the channel
<clever> kqb: if you change the stateVersion, it will upgrade postgresql, and then psql cant read its own database files, and everything breaks
<clever> kqb: the whole point of stateVersion, is so nixos knows what version your state came from
<{^_^}> kqb: Setting stateVersion to the latest release doesn't upgrade anything and can only break your setup at best. To actually upgrade NixOS see https://nixos.org/nixos/manual/#sec-upgrading. If you want to update the stateVersion option regardless, Ctrl-F for "stateVersion" in https://nixos.org/nixos/manual/release-notes.html to see things that need to be manually migrated with the new value.
<clever> ,stateVersion kqb

2020-01-03

<symphorien> you can always change stateVersion, see what fails, find the corresponding github issue and fix the problem by hand
<clever> Raito_Bezarius: when nixops creates a machine, it will read the current version (whatever it booted with) and remember that as your stateVersion
<Raito_Bezarius> Thus, the question becomes: how can I provision a machine with the stateVersion (X) of my choice when I am restricted on the version of NixOS (17.03)?
<symphorien> Raito_Bezarius │ There is no state atm << note that there is state everywhere. For example, people who had no stateVersion defined have recently had problems with systemd-timesyncd failing after it's state got corrupted. So you might have state after all.
<Raito_Bezarius> and I understood that stateVersion was somehow assuming this role
<Raito_Bezarius> can I specify a stateVersion = "20.03" ?

2020-01-02

<{^_^}> Setting stateVersion to the latest release doesn't upgrade anything and can only break your setup at best. To actually upgrade NixOS see https://nixos.org/nixos/manual/#sec-upgrading. If you want to update the stateVersion option regardless, Ctrl-F for "stateVersion" in https://nixos.org/nixos/manual/release-notes.html to see things that need to be manually migrated with the new value.
<flokli> ,stateVersion
<flokli> eoli3n_: you never ever want to set stateVersion to something else than the one you set on boot

2019-12-24

<{^_^}> Setting stateVersion to the latest release doesn't upgrade anything and can only break your setup at best. To actually upgrade NixOS see https://nixos.org/nixos/manual/#sec-upgrading. If you want to update the stateVersion option regardless, Ctrl-F for "stateVersion" in https://nixos.org/nixos/manual/release-notes.html to see things that need to be manually migrated with the new value.
<clever> ,stateVersion
<Yaniel> to begin with you should not touch stateVersion like, ever

2019-12-18

<{^_^}> Special commands: find tell locate expand guys - Commands sorted by use count, page 0 (use ,<n> to view page <n>): help libraries unstable escape'' library declarative howoldis unfree ping paste escape" callpackage pinning -a profiling ask overlay pr which-channel stateversion nixlang++ wololo channels xml botsnack ifd xy imperative cache exec fancy-uninstall pills tofu invite haskell loot home-manager matrixbridge pointers stuck tias cloak

2019-12-04

<{^_^}> Shoubit: Setting stateVersion to the latest release doesn't upgrade anything and can only break your setup at best. To actually upgrade NixOS see https://nixos.org/nixos/manual/#sec-upgrading. If you want to update the stateVersion option regardless, Ctrl-F for "stateVersion" in https://nixos.org/nixos/manual/release-notes.html to see things that need to be manually migrated with the new value.
<clever> ,stateVersion Shoubit

2019-11-23

<clever> pistache: stateVersion should be set to release, when nixos-generate-config first makes the config, and then left at that value
<{^_^}> Setting stateVersion to the latest release doesn't upgrade anything and can only break your setup at best. To actually upgrade NixOS see https://nixos.org/nixos/manual/#sec-upgrading. If you want to update the stateVersion option regardless, Ctrl-F for "stateVersion" in https://nixos.org/nixos/manual/release-notes.html to see things that need to be manually migrated with the new value.
<samueldr> ,stateVersion

2019-11-22

<{^_^}> Special commands: find tell locate expand - Commands sorted by use count, page 0 (use ,<n> to view page <n>): help libraries unstable escape'' library declarative unfree howoldis escape" ping paste callpackage -a pinning profiling ask overlay pr wololo nixlang++ which-channel botsnack stateversion xml imperative xy cache fancy-uninstall pills channels exec ifd invite haskell loot home-manager stuck pointers tias tofu cloak dontask escape-special

2019-11-09

<lucus16> clever: What's your stateVersion?

2019-11-02

<equivrel> How does system.stateVersion work? I thought I bump the number before I want to upgrade, but a comment in the 19.09 release notes makes it sounds like I want to keep it at 19.03 until after the upgrade? The combination of nix-channel and stateVersion is a bit confusing...

2019-11-01

<clever> kolaente: nixos uses the stateVersion to keep you on an older postgresql, until you read the release notes, and follow the migration directions
<clever> any attempt to change stateVersion (automated or manual) will result in postgresql loosing the database
<clever> and nixos uses stateVersion to figure out what format you used when you first installed, so it can keep using that format
<clever> zeta_0: the stateVersion shouldnt be changing, and the whole point is to record what version your "state" is
<zeta_0> kolaente: yeah nix forces you to do things differently than your used to, in the case of stateVersion when you do the 2 commands to upgrade, then state version gets changed automatically
<{^_^}> kolaente: Setting stateVersion to the latest release doesn't upgrade anything and can only break your setup at best. To actually upgrade NixOS see https://nixos.org/nixos/manual/#sec-upgrading. If you want to update the stateVersion option regardless, Ctrl-F for "stateVersion" in https://nixos.org/nixos/manual/release-notes.html to see things that need to be manually migrated with the new value.
<clever> ,stateVersion kolaente
<clever> ah, generating the stateVersion on first boot

2019-10-29

<Ariakenom> my virtualbox looks broken. it may be because i changed stateVersion when I shouldnt have? I changed it months ago, should I change it back?

2019-10-26

<srhb> "stateVersion? probably not important!"
<exarkun> in the changelog I see that systemd-timesyncd has some interactions between stateVersion, 19.03, and 19.09

2019-10-23

<evils> oh, ignore my stateVersion, i'm building from a local git xD
<evils> huh, i've got kicad-with-packages3d in my configuration.nix with stateVersion 19.09, my nix-env uses channel nixos-unstable, that gets me the same derivation as digitalkiwi, also crashes

2019-10-22

<{^_^}> Special commands: find tell locate expand - Commands sorted by use count, page 0 (use ,<n> to view page <n>): help libraries unstable escape'' library unfree declarative howoldis ping escape" paste callpackage overlay -a ask pinning profiling pr nixlang++ which-channel imperative wololo xy cache fancy-uninstall pills stateversion xml botsnack exec channels invite loot haskell home-manager stuck ifd pointers tias escape-special timer dontask nur
<LinuxHackerman[m> you can wipe all your state and set a new stateVersion
<eyJhb> Wait, I might be misunderstanding stateVersion
<eyJhb> StateVersion is 19.09, isn't that correct?
<LinuxHackerman[m> you need to have your stateVersion set right

2019-10-17

<tokudan> zeta_0, keep stateVersion and just change the channel
<zeta_0> i just have to change: `stateVersion = "19.03"` to `stateVersion = "20.03"`in configuration.nix and home.nix before changing the channel and running an upgrade ?
<{^_^}> Special commands: find tell locate expand - Commands sorted by use count, page 0 (use ,<n> to view page <n>): help libraries unstable escape'' library unfree declarative howoldis ping escape" callpackage paste overlay -a ask pinning profiling pr nixlang++ which-channel imperative xy cache fancy-uninstall pills stateversion wololo xml botsnack exec invite channels loot haskell home-manager stuck ifd pointers tias escape-special timer dontask nur

2019-10-16

<infinisil> flokli: Visibility for the end user? This shouldn't be a problem, they'll get an error if they don't set this option. Visibility for the module authors? Should not be a big problem, because the global stateVersion won't exist anymore but be replaced with a message explaining how to use mkStateVersionOption
<infinisil> Same for all others that need stateVersion
<infinisil> flokli: Yeah maybe, but as discussed in #65314, I think the best fix for the current mess is to have per-module stateVersions
<flokli> We might just want to increase stateVersion to something not matching the release number, like 3000, and then just increment the "suggested value" on every state migration we have to do, or every release
<infinisil> Unfortunately not setting stateVersion is more common than I'd like
<infinisil> There is effort to make stateVersion mandatory (which imo should have been done from the beginning): https://github.com/NixOS/nixpkgs/pull/65314
<infinisil> The problem here is not having set stateVersion in the first place
<__red__> then, because of something else - I set my stateVersion to 19.09
<infinisil> No, stateVersion doesn't do any reverting or such
<infinisil> So you could just fix it by setting stateVersion to 19.09
<__red__> so I should set my stateVersion to 19.09?
<__red__> did the stateVersion bump then for unstable-small?... and how would I see that commit? where would it be?
<infinisil> Not setting state version and updating is like setting stateVersion to the latest version
<{^_^}> Setting stateVersion to the latest release doesn't upgrade anything and can only break your setup at best. To actually upgrade NixOS see https://nixos.org/nixos/manual/#sec-upgrading. If you want to update the stateVersion option regardless, Ctrl-F for "stateVersion" in https://nixos.org/nixos/manual/release-notes.html to see things that need to be manually migrated with the new value.
<infinisil> ,stateVersion
<infinisil> __red__: Set stateVersion!
<gjabell> isn't the whole point of the stateVersion to prevent that from happening?

2019-10-15

<clever> ,stateVersion
<{^_^}> Setting stateVersion to the latest release doesn't upgrade anything and can only break your setup at best. To actually upgrade NixOS see https://nixos.org/nixos/manual/#sec-upgrading. If you want to update the stateVersion option regardless, Ctrl-F for "stateVersion" in https://nixos.org/nixos/manual/release-notes.html to see things that need to be manually migrated with the new value.
<sphalerite> Zer0xp: was stateVersion not accompanied by a comment saying not to change it in your config? :/
<sphalerite> Zer0xp: just leave stateVersion alone, including when upgradin

2019-10-11

<danderson> there were other changes in relnotes that depend on stateVersion, but not for software I'm running
<danderson> but it has an activation shim to move the state around if stateVersion <19.09
<danderson> I see. That said, all those things should show up in dry-build and dry-activate as changes. There was one change in 19.09 that cared about stateVersion, and it was a one-time thing
<clever> danderson: if you remove or change the stateVersion without reading them, then you may break the things its meant to not break, but you could just go ahead, and then fix whatever is broken
<clever> danderson: postgresql uses stateVersion to control the version of psql, so you can access your db, and you must manually export it to .sql, upgrade, then re-import
<clever> danderson: in general, you need to figure out what services you use, that care about stateVersion, and then investigate what changes it will cause
<danderson> qyliss: that sounds like stateVersion is never meant to be updated, even though the config comment implies it should be.
<{^_^}> Setting stateVersion to the latest release doesn't upgrade anything and can only break your setup at best. To actually upgrade NixOS see https://nixos.org/nixos/manual/#sec-upgrading. If you want to update the stateVersion option regardless, Ctrl-F for "stateVersion" in https://nixos.org/nixos/manual/release-notes.html to see things that need to be manually migrated with the new value.
<qyliss> ,stateVersion
<danderson> Parts of the release note mention having to stay at 19.03 for the first activation, because some services need porting of their state. Once that's done, is it safe to set the stateVersion to 19.09?

2019-10-09

<{^_^}> Setting stateVersion to the latest release doesn't upgrade anything and can only break your setup at best. To actually upgrade NixOS see https://nixos.org/nixos/manual/#sec-upgrading. If you want to update the stateVersion option regardless, Ctrl-F for "stateVersion" in https://nixos.org/nixos/manual/release-notes.html to see things that need to be manually migrated with the new value.
<infinisil> ,stateVersion