Renames stateVersion to stateEpoch #50112
Conversation
This is the first part, the noisiest part. The idea is to decouple that option from the version of NixOS. Why? There may be verions where `stateVersion` does not incurr incompatible changes! There could be development (unstable) versions with multiple conflicting changes! Decoupling that flag from the operating system version should, in theory, better represent the intent at all time.
... rather than using the NixOS version. This change is to reduce the support questions like this: > I changed `stateVersion` in my `configuration.nix` and NixOS hasn't > been upgraded to the next release. What gives? Using the release version as a marker to decide between stateful schemas is in itself a good idea, but might not be the best interface to present to the end-users. Having a monotonically incrementing opaque number will reduce confusion. The number `100` has been chosen as: * It is bigger than 18.09 when compared as a version * Allows us to start "at zero" in a new range. The number would have been `1` if possible, but existing `stateVersion = xx.yy;` makes it harder to implemented in such a way.
So yeah, good point there, this makes it a tad harder to describe the changes in the release notes. Though, while the number itself is uncoupled from the releases, the notes about incompatible changes could realistically still be described in the release notes. Though, since not all changes requiring an increase in |
|
While this may cause people to not suddenly bump the variable on their own despite the warnings, I think it's going to increase the support burden, not the other way around, since it still has the same meaning but now has an extra layer of indirection in order to actually understand what's going on. In general, I doubt making the meaning of a certain value more opaque is an improvement. I think it would be preferable to improve the documentation in both the generated warning and in the actual docs -- a link with some long-form prose in the "don't do this"-comment would be especially good. |
|
I personally approve I also don't really see what extra layer of indirection there is: it's just comparing a version vs. comparing a digit, it just decouples orthogonal concerns (releases vs. backwards-compat-breakage). Finally, I think |
|
What we'd really need is a state version for everything that needs state separately. So nginx has its state version, postgresql, etc. These are 0 by default and increase on every state incompatible update. Advantages:
In addition, these state versions could be stored alongside the data itself, in So if we're gonna change how this state version thing works, why not go all out and implement it properly. |
|
What we'd really need is a state version for everything that needs state separately. So nginx has its state version, postgresql, etc. These are 0 by default and increase on every state incompatible update. Advantages:
- Allows users to only update/migrate a single part
- We could implement automatic migrations for some parts and only provide manual ones for others
This would be great! even though it might increase the burden of
updating.
In addition, these state versions could be stored alongside the data itself, in `/var/lib/nixos/stateversion` preferably. To be able to access these values in the configuration, we should modify `nixos-rebuild` to read the target hosts `stateversion` file and pass it to the configuration at the start. This has the advantage that nobody needs to track this version in their configuration, which I always thought was a bit annoying and unnecessary.
That would make building the configuration impure. I much rather have
people who want that just have `/var/lib/nixos/stateversion.nix`
defining their state versions and having a
```
imports = [ /var/lib/nixos/stateversion.nix ];
```
so that only people who want impurity will have it.
|
Ah right, good point. Now what we'd need is a separate command So how about extending |
|
👎 on doing this.
👍 on splitting into tiny per-service pieces.
See also 1f0b692#commitcomment-29001452 and 4d1332e#commitcomment-30039646
|
|
@samueldr I think this should be turned into an RFC, and it would basically never merge otherwise, isn't it? |
|
Thank you for your contributions. This has been automatically marked as stale because it has had no activity for 180 days. If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity. Here are suggestions that might help resolve this more quickly:
|
stale
bot
added
the
2.status: stale
stale
bot
removed
the
2.status: stale
|
I marked this as stale due to inactivity. → More info |
stale
bot
added
the
2.status: stale
|
Closing as it is abandoned. |
Motivation for this change
Initially thrown on the wall 2018-10-07.
This change is to reduce the support questions like this:
Using the release version as a marker to decide between stateful schemas is in itself a good idea, but might not be the best interface to present to the end-users.
Having a monotonically incrementing opaque number will reduce confusion.
The number
100has been chosen as:The number would have been
1if possible, but existingstateVersion = xx.yy;makes it harder to implemented in such a way.Additionally, decoupling the release version makes it so it is possible to have concurrent incompatible changes in
unstable, while staying compatible, making for a better rolling-release approximation.Things done
sandboxinnix.confon non-NixOS)nix-shell -p nox --run "nox-review wip"./result/bin/)nix path-info -Sbefore and after)Expectations
A bit of bikeshedding. A bit of criticism about the implementation.
Please consider the idea and propose better implementations, but don't hang yourself up on details of the implementation. I'm more interested in the big picture than corner case things. Once the big picture is better unveiled, and everything falls in place, the details can be worked out. Thanks.