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:
We do have some docs on this for a couple years already: NixOS 23.11 manual | Nix & NixOS – 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.
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?
Yes, instead of an example schedule we could indeed make it the schedule.
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.
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 https://github.com/NixOS/rfcs/commit/8a3ba49393455fcf426488aef8b6d27d428c640c.
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 [RFC 0080] Change NixOS releases to YY.05,YY.11 by jonringer · Pull Request #80 · NixOS/rfcs · GitHub 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.