I’ve been using NixOS fairly recently, and first installed 22.11 but 23.05 released shortly after and I’ve been on it since. It’s been really solid, but toward the last couple months I think I want to try unstable to keep more up to date.
I think the upcoming release would be a good time to make the switch to unstable because the breaking changes notes will be helpful.
Where do breaking changes get posted for the unstable train? Is there a way to see what will change before a rebuild test?
The breaking/notable changes are collected in the respective release notes section of the manual as they happen. https://github.com/NixOS/nixpkgs/blob/9ac60d31c0fa0bb2bbd7d166c4eaf19e9ba8db35/nixos/doc/manual/release-notes/rl-2311.section.md for 23.11 for example. The current master branch will be branched off into the 23.11 release branch, so in the past few months, that’s where breaking change notes on the unstable channel were collected.
There’s no specific “good” time to switch to unstable though as these notes are always there and breaking changes come in all the time. The exception might be this time of the year since breaking changes are now restricted but it’s honestly not a large difference.
Additionally, there is Breaking changes announcement for unstable where some (not all) breaking changes or changes that need more thorough testing only possible with a wide amount of use-cases or changes that might be less visible (such as core library updates) are posted.
I must say that, generally, the unstable channel is pretty stable. While they do happen from time to time, breaking bugs are rare. Additionally, it’s not like you’re stuck when there is one since you can simply rollback the Nixpkgs update (it’s still NixOS afterall!).
The most “critical” thing you might need to do from time to time is change up how you configure certain things because the interface was changed. You get an eval error for this telling you what changed and you can usually trivially change it.
This too is rather rare though. Happens 1-2 times per year for me perhaps? In all likelyhood, an upgrade from stable to unstable can happen without any changes to the config necessary and will work just like before.
There are also odd edge cases where it ends up being more “stable” than stable, mostly around third party kernel modules, simply because it takes longer for hotfixes that adapt those modules to newer kernels to land on stable.
While I tend to be an advocate of using stable, if you’re confident in your nix, and don’t mind using bleeding edge software versions, I don’t really think there’s much of a reason not to use unstable. Unlike traditional rolling release distros you even have rollbacks for the worst case.
I just wanted to insert a tiny concern: I’m not sure how updates are ranked whether they are to be added to stable or not, but lately there were some minor inconveniences, as switch of buildFHSEnv to use bwrap with most namespaces unshared, that broke some of my existing setups, and then recently it was updated to not use any unshares by default, that broke some of my setups again, all within “stable” nixos release branch.
In my understanding both such changes had to be done on release version change…
Also there was some LD_LIBRARY_PATH related stack smashing issue that also made it’s way into stable for a short period of time.
Again, nothing broken too hard, just inconveniences. Just wanted to point out that nixos release understanding of stable release seem to be somewhat different from what I’m used to.
Neither of those changes were backported to a stable release. The former change was tested for a month in unstable and then made it into 23.05 as a regular “breaking” change (it even had a release note).
buildFHSEnv: disable security features by default by rnhmjoj · Pull Request #253982 · NixOS/nixpkgs · GitHub was not backported: [Backport release-23.05] buildFHSEnv: disable security features by default by github-actions[bot] · Pull Request #262726 · NixOS/nixpkgs · GitHub. It will be in the next release.
To make this clear: Stable means breaking changes happen at fixed times with new release numbers requiring explicit opt-in (manually change channel URL or flake input) rather than breaking changes coming in at possibly any time (unstable).
Stable does not mean “never changing”. No breaking changes ever is not possible. Like the rest of conservatism, it simply does not work long-term.
That one was a dormant pre-existing bug in buildFHSEnv which was triggered by a necessary upgrade of an unrelated core library. A fix was done and backported, despite some discomfort from my side as this fix could still break something else somehow.
i think i have a mixture of stable nixpkgs in system and unstable in those flakes… sorry, it was my bad all along.
I guess i need to make sure for my flakes to use system’s nixpkgs by adding that to flake registry as part of the system setup.