NixOS 24.11 released

Hello, we’re glad to announce NixOS 24.11 Vicuña was released earlier today.

We saw quite a significant increase of contributors between 24.05 ( 2491) and 24.11 ( 2669). We’re glad to see more contributors with each version which is released and we’d like to thank everyone for participating.

A major highlight of this release is the Darwin rework which @reckenrode & @emily had a large involement in. Nix was upgraded to 2.24 and we’re using the new Rust based switch-to-configuration.

NixOS 24.05 Ukari is supported until the end of 2024, it has been marked as “deprecated” and wil be dropped in about 1 month from now.

We’ll be doing a release retrospective on 2024-12-06T19:00:00Z. The link will be posted on the Release Management Matrix two days before the retrospective.

I’d like to thank @wegank for being the other release manager. @getchoo & @GetPsyched for their work as the release editors. @vcunat for the staging work, @emily for their involvement on trying to push things through. @riotbib for the artwork, and @hexa for the infrastructure which we really needed when we ran into the curl netrc regression which ultimately delayed the release.

Enjoy the release!

106 Likes

And thank YOU Tristan (@RossComputerGuy) for being the release manager! Hip hip hooray for another NixOS release.

12 Likes

Excellent! Thanks for all the work!

8 Likes

This update made me worried because version 24.05 will only be supported for another month, but 24.11 has an error in the hyprland package.

Please report individual package/service issues as a new topic or on github (if not already reported).

7 Likes

Thank you everyone for your hard work, it was a smooth upgrade with the usual deprecation cleanup (mostly gnome’s shift to top of pkgs). I also treated myself to try niri which is an interesting DE and more solid than I expected.

8 Likes

Only minor changes required on my end, so a rather seamless update. Thanks for the hard work!

1 Like

Now as the release is finally happened, can I ask why the initial release date was not the end of the month like in the past releases?

It’s mentioned in the post.

2 Likes

I believe they were asking why the initial date was Nov 22, not why it was delayed

2 Likes

Yes this is what I meant.

1 Like

We had it on the 22nd originally so we didn’t have to stress if there was a delay and it was a more convenient timeline for release.

9 Likes

Sorry if this is an obvious question, but when I went to bump my NixOS flake to 24.11, I notice that there is no tag for NixPkgs 24.11 yet. Is it coming or is there a smarter way to refer to a release in my flake?

1 Like

nixos-24.11 is the branch. A tag wouldn’t make sense since active development is happening on said branch.

2 Likes

(Definitely do not use that tag as a flake input, though, or you’ll not get updates.)

3 Likes

It’s generally okay to track the release branch instead of the tag. The intent of the tag is just to snapshot where the release was, and if you need it, you can use it. I think people were getting them confused (as in, not just using the latest nixos-##.## commit, which is merged after all the NixOS tests have run, and the tag is simply the first instance per release cycle of that). I know I did when I was new to nixpkgs.

Can we make 25.05 codenamed “wolverine”? XD

EDIT: Just found out its “Warbler”. dang.

1 Like

Is it just me or does anyone else also want to have the previous release supported for more than 1 month? I don’t mean to backport all the things, but security fixes and minor upgrades?

My reason for this mindset is that I don’t find the time to upgrade my machines from time to time. I run stable because I don’t need to (or have the feeling that I should) update every other week… Sometimes I run stable for well over 1 month after the next stable is already released, just because I cannot get around to read all the breaking changes and upgrade all my machines.

Anyone feeling the same?

2 Likes

What you describe is precisely the extent to which we maintain stable to in the regular case.

I’m sorry but that’s your problem to solve, not ours.

You need to update and reboot every single week if you want a secure system, even on stable. Dozens of CVEs get fixed every week in the kernel alone.

This is not a matter of feeling but how much burden you can place on us maintainers. The 1.5 months we have right now are already too much IMHO.

There was a company exploring offering paid LTS a while ago; you could explore that if breaking changes two times a year is too much for you.

8 Likes