NixOS 26.05 release retrospective

Development NixOS Releases
1

Hello everyone,

we are @yayayayaka and @jopejoe1, the release managers of the latest NixOS release, NixOS 26.05 “Yarara”.

In our release announcement on discourse and GitHub we invited the community to a Jitsi call to provide a room for feedback about the past release cycle. That call happened on June 3rd 2026 18:00 UTC and last around 45 minutes.

In this thread we provide summary of the points discussed. If you have more feedback, you are more than welcome to provide them here as a reply to this thread.

<3,
yaya and @jopejoe1

NixOS 26.05 release retrospective

staging-next iterations

The 26.05 release cycle had only staging-next iteration. This was due to delays in the previous iteration. To allow more time for the staging-next iteration to finsh before branch-off, the release managers decided to postpone the branch-off and the final release by a few more days. We still managed to announce the release by the end of month, however.

The timeframe of each staging-next iteration (as suggested by RFC85) does not match with reality anymore, as these take more than one week nowadays.

The time between the staging-next merge and the official release was considered too short. Some regressions such as the GDM+Niri desktop setup could not be fixed in time and affected a considerable amount of users.

As a result, the release managers will seek a conversation with the staging team to rethink the timeline of a future release process to allow more time for the staging-next iterations.

Breaking changes after feature freeze

It was noted that some breaking changes were merged after the restriction on breaking changes and the release managers were encouraged to revert more PRs causing issues.

Clarification on deprecation policies within nixpkgs

In response to the removal of the entire nodePackages package set, it was noted that there is still no clear policy on when and how to deprecate/remove things within nixpkgs. Yaya mentioned NixOS/nixpkgs#520061 as an already ongoing discussion on that topic.

switch during NixOS upgrade

The official NixOS manual mentions nixos-rebuild switch --upgrade as a mean to upgrade to a new release. This was critizised in the meeting as this could introduce hard to solve problems during the upgrade.

Instead of switching, it should be generally recommended to nixos-rebuild boot followed by a system reboot to upgrade NixOS to a new release.

The release managers have taken note of that feedback and will propose a change of the documentation.

For future releases, it was also suggested to make the release upgrade a switch inhibitor.

Cleaning up old NixOS module config

It was suggested to clean up old NixOS configuration that applies to old, unsupported NixOS releases only (aka system.stateVersion < 25.11) in the future.

Nixpkgs/NixOS Release notes

Coordination with release editors

The release managers were faced with the problem of unfinished release editing. They had to take the time to fix missing internal links and sorting release notes into the right handbook (NixOS vs. nixpkgs manual). This delayed the announcement of the final release by a several hours.

This could have been avoided by having the release managers check the state of the release notes at least one day in advance, so this is entirely on us release managers :slight_smile:

The release managers will update the release manual to ensure the final review of the release notes happens a little earlier than on release day.

Participants of the meeting mentioned that release editing often happened at the very last minute and recommended to start with the release editing earlier.

Summarizing removals

It was suggested to summarize module removals to make the section about backbard incompatibilities easier to read.

Release Wiki maintenance

The release managers noticed more outdated information regarding the release process in the NixOS Release Wiki and will provide more Pull Requests bringing the documentation back in sync.

Closing

Once again, thank you all for making this release possible and I am looking forward to release the next version of NixOS (26.11 “Zokor”) in coordination with a new release manager!

Until then! <3
yaya

49 Likes
NixOS 26.05 released
Upgrade command experience
2

Not entirely sure if I should be commenting in this thread, apologies in advance if I’m not supposed to.

I was one of the people who noted that breaking changes were merged during the freeze window, largely because running my own CI is running against unstable, so any BC cause failed builds to pop up.
This isn’t supposed to be a complaint really, the changes I noticed were comparatively minor and eval-time, so it wouldn’t have caused any larger issues.

Anyway, what I wanted to point out/ask about is whether the GitHub Codeowners feature or anything similar could’ve helped here?
The changes I ran into actually had entries in the BC section of the release notes, so if there was a mechanism during the release to tie the merge of anything with breaking changes to an approval of the release managers that would, in theory, solve the problem I think.
From what I can tell it’s a matter of whether that really works as an implementation, whether the extra effort (for the release managers having to approve everything) is justifiable, and whether or not this could lead to adverse effects where people stop writing release notes and get breaking changes merged with no release notes at all.
Also of course whether building the mechanism for this is actually feasible.

Compared to something like an RSS feed to the release notes and reverting any changes which do touch the breaking changes section this would actually be preemptive and prevent a merge in the first place.

Really just throwing this out as an idea, with no actual practical experience on whether or not this can actually work.

Also, thank you very very much for your work on the release in general, much appreciated <3

3 Likes
3

you can have a nixos-26.05 installation that has system.stateVersion arbitrarily old, right? isn’t that the point of it? so old state versions aren’t necessarily “unsupported” per se

it seems reasonable that you might sometimes want to force people into a data migration if supporting the old form is difficult, but that can’t be by forcing them to update their global stateVersion – it’s currently not practical for people to even list all the effects that would have, until something like https://github.com/NixOS/nixpkgs/pull/509450 is adopted

8 Likes
4

Just to echo

It was suggested to clean up old NixOS configuration that applies to old, unsupported NixOS releases only (aka system.stateVersion < 25.11) in the future.

This doesn’t make any sense IMO. The docs very prominently say, for all intents and purposes, that there is no upgrade path for stateVersion. So removing old ones will break people who have been told for years at this point “do not touch this”.

7 Likes