The thread in question for reference: Seeking Feedback: Paid Long-Term Support (LTS) for NixOS starting with 24.05
1 Like
I think nixos needs double the people and financing to afford extended backporting (especially considering how vastly some packages change over time), so what we have is somewhat of a compromise.
So that’s what we get if we choose to use nixos, but this update schedule is at least very predictable, so you can plan the time ahead for migrating your configurations. And changes are documented and mostly supported by errors and warnings that help you guide your config migration.
4 Likes
NixOS 24.11 retrospective - Jitsi Meet
3 Likes
I believe the lack of an immutable Nixpkgs 24.11 tag is a breaking change for those who only perform cluster-wise updates on stable releases, and rely on a meaningful tag to identify these revisions.
The mentioned tag branch-off-24.11 has a confusing and inconsistent name, and was committed two weeks before the final release, which is also very confusing. Many have suggested using branches instead of tags to stay up-to-date with the latest development, which I consider the opposite way to keep reproducibility and to reduce unnecessary derivations. Explicitly pinning a revision in flake inputs is another workaround, but could become unmaintainable for large amount of projects over the long term.
Can we have some serious clarification or documentation on this change, so that we can adjust our updating strategies accordingly?
afaik, relying on a branch and not an exact tag has always been the recommendation. if you use a tag, you will not get the important bugfixes and security fixes that the branch provides.
4 Likes
The only thing that changed, is that the tag got renamed from 24.11 to branch-off-24.11. The intent of this was to show, that the tag should not be used, because it lacks the critical security updates which make up the stable channel and it’s merely a point in time at which the release split of. This was also the case previously afaik event though the names were different. So policy wise nothing basically changed, it is still recommended to use the nixos-* branch for stable releases.
A system without updates is sadly not a secure system 
13 Likes
I believe the lack of an immutable Nixpkgs 24.11 tag is a breaking change for those who only perform cluster-wise updates on stable releases, and rely on a meaningful tag to identify these revisions.
Off topic to the actual content of the thread, but if you want to maintain the same rev over a larger amount of machines you want to use some pinning tools like niv or just flakes (depending on what you like more), but using the branch-off tag for the whole release cycle is just a big shoot in your feed as you never will receive any update and you are basically running unpatched instances for the whole time (-the few days the Tag is actually up2date)
Can we have some serious clarification or documentation on this change, so that we can adjust our updating strategies accordingly
Using the branches is the correct update strategy as everything else will not update but is a pure snapshot of a specific time
4 Likes
Thank you guys for clarifying that renaming the branch off tag is a careful decision to prevent further unintended usage and improve overall system security for NixOS users. I was trying to find some information about the missing tag and hopefully not to start a debate on security versus maintainability. Maybe it’s worth trying to migrate my systems from a stable tag to a branch, or at least it can be pinned to a static revision if the head doesn’t work well.
4 Likes
Is there a document that clarifies the relation between different nixpkgs branches? I mean, what is the difference between release-24.11 and nixos-24.11? In my flakes, should I use the former or the latter?
https://wiki.nixos.org/wiki/Channel_branches
tl;dr release-24.11 is what hydra runs, so usually you want to be on nixos-24.11, which is when the checks passed and the binary cache should be populated
7 Likes
I have to admit that even after a few years using NixOS this is still something unclear for me.
1 Like
Ironically the best place to see this would be the contributors’ guide.
For unstable/stable respectively, regular PRs (changes) are sent to master/release-2x.xx, and mass rebuild changes are sent to staging/staging-2x.xx (which eventually get back to master/release-2x.xx).
Once they are all built and nixos tests are run, you get nixos-unstable/nixos-2x.xx, so these two are the channels to pick from on NixOS in most cases.
There’s also the -small variants that build/test a smaller subset of packages before advancing the channel, and unstable uniquely has the nixpkgs-unstable branch (no nixos tests run) and some nix-darwin branch that I’ve never looked at. These can also be used if you don’t use NixOS or have some unique scenario.
2 Likes
Yes, that was us (Cyberus Technology). We have since decided to go ahead and offer long-term support. We are still in the early days, but if you need support for 24.05, please feel free and contact us. Either via our website or you can DM me here on Discourse.
9 Likes