Warn when End Of Life

[roberth]

Is your feature request related to a problem? Please describe.

Sometimes users find themselves running an old version. Possibly only after a long and unnecessary debugging session.

• E.g. File set library tracking issue and feature requests nixpkgs#266356 (comment)

Describe the solution you'd like

• When the current time is larger than the planned end-of-life date of a Nix release, print a warning.

Warnings can be annoying.

• Perhaps only print a warning once a day.
• Allow the warning to be disabled with a setting.

Warnings will throw off the test suite

• Disable the warning in the functional tests.

Experimental features suffer more significantly from this problem.

• Perhaps go EOL sooner if experimental features are enabled.
  • I believe we might not be ready to support such a release cadence confidently, but perhaps in a year or two we may.

Describe alternatives you've considered

• Don't help users with upgrading
• Only enable the warning when the official installer is used. E.g. NixOS should nag on its own.
• Brown-outs

Additional context

Priorities

Add 👍 to issues you find important.

[thufschmitt]

That sounds like a fairly good idea.

We probably want to give it a bit of slack wrt the eol date (if only because we'll have to embed it in the binary, and we can't predict the future), but that sounds like a cheap and worthwhile thing to do.

Only enable the warning when the official installer is used. E.g. NixOS should nag on its own.

If we make this configurable with a configuration option (which we should probably do), then it's just up to the NixOS maintainers to set the right option

Experimental features suffer more significantly from this problem.

* Perhaps go EOL sooner if experimental features are enabled.
  
  * I believe we might not be ready to support such a release cadence confidently, but perhaps in a year or two we may.

I still hope that we can get (again) to the point were a broad 99% of the Nix users can live without experimental features, in which case this case would mostly solve itself

[roberth]

slack wrt the eol date

Patch releases should be sufficient to propagate a postponement. If users don't catch patch updates, they have a security problem. (Not necessarily from Nix, but from their lack of general updates)

users [should be able to] live without experimental features

Exactly. When we're there, we can have an "experimental EOL" that's shorter than normal EOL.

Thinking again, I kind of like the idea of pushing flake users on 23.11 to update in 3 months from now when a bunch of stuff needs broad testing. Realistically, it seems that nixos-unstable users will be sufficient for experimental testing.

[nixos-discourse]

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/2023-12-08-nix-team-meeting-minutes-110/36721/1

[tpwrules]

I have found this very annoying when using some other software and would strongly disagree with adding it. I deploy Nix (and that other software) to static systems that aren't really expected to be upgraded on a fixed schedule and having these messages pop up harms users. If it's added, there must be an option to unconditionally disable it.

[thufschmitt]

Discussed during the Nix maintenance team meeting on 2024-01-12. Morally approved

- @thufschmitt in support provided there's a flag to disable that behavior - @edolstra a bit meh, but not really opposed - @roberth: We can start very flexible (one year), just to rule out very old stuff

[nixos-discourse]

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/2021-01-11-nix-team-meeting-minutes-115/38277/1