Release schedule for NixOS?

Twice a year we release NixOS. During every cycle a lot of changes are delivered, and especially before branch off we try to get the things in we really want to get in, typically overloading Hydra in the process resulting in delays.

I propose we have a schedule so that everyone can see what changes we expect and when. Some things to include:

  1. branch off date
  2. release date
  3. when we intend to upgrade the various sub package sets
  4. when we accept the latest feature changes in core parts such as stdenv

We do have some docs on this for a couple years already: NixOS - NixOS 21.05 manual – all times there are relative… but at least release notes do hint that the next one should come as expected

End of support is planned for end of October 2019, handing over to 19.09.

Feel free to suggest improvements.

1 Like

Right, forgot about that one. I would like to have a schedule with actual dates. Not sure where to put it though. Maybe just a pinned issue here on Discourse?

1 Like

We could keep updating that example schedule in-place.

1 Like

Yes, instead of an example schedule we could indeed make it the schedule.

1 Like
  • Feature freeze/branch off: I announced the feature freeze for 19.03 with just over a month of advance in NixOS 19.03 feature freeze.
  • Release: In that topic, I mentioned a rough time when I was hoping to do the release, but intentionally not a specific date, simply because it’s unpredictable when it’ll be ready in terms of the blockers and such (and in this case, my availability around when I had originally planned was unfortunately a bit different than I had hoped).

My interpretation was that package subsets and stdenv shouldn’t be exceptions to the feature freeze, and should take place before it as well. I’m guessing the fact that this didn’t happen in practice was a failure on my part to communicate this (we should probably actually define the feature freeze?). @FRidh is there a reason for the package sets and stdenv not to be covered by the feature freeze? Or were you thinking of having an earlier cut-off date for those?

Or were you thinking of having an earlier cut-off date for those?

Indeed, an earlier cut-off for those.

Changes in the package sets can cause quite some breakage elsewhere in the tree. Additionally, the load on Hydra is typically pretty high around this period. Personally, I would prefer to fix the package sets a bit before branch-off, and possibly delay branch-off by a week to compensate.

1 Like

It could be a convention to e.g. avoid the staging → staging-next step in the period (and use directly staging-next for stuff that just must be in the upcoming release for some reason).


In several threads releases are being discussed. As mentioned in the opening post I am of the opinion we need to have a clear release schedule, and so I started working on an RFC RFC 80: NixOS release schedule · NixOS/rfcs@8a3ba49 · GitHub.

I think we need a freeze period before branch-off. In the proposal I mention only “core changes”, without yet defining what that is. Definitely stdenv and systemd, but also I think the sub package sets.


So if I understand correctly, you’d start the freeze for 21.05 in March 2021? Basically we’d have the same release schedule, but the naming would be more in line with reality?

I’d like that.

It’s better to say “You can already use 21.05 even though it’s April, we believe it’s stable” than “You try using 21.03 but it will be a while before it’s stable”.

I was going to propose something almost in the other direction.

If gets ratified, then the majority of ZHF will just be fixing failing builds.

I was going to propose a schedule where we postpone a staging cycle, and conduct ZHF in that two week period, using staging-next for fixing large-regressions. Essentially get master into a “release ready” state, then branch-off. Do a week of final QA and release manager items, then release.

Removing a lot of risk from the “master” branch seems way more sane then us cramming staging PRs right before branch-off, then trying to fix all the breakages in two divergent branches.

1 Like