21.05 Release Schedule

Hello everyone, you’re friendly neighborhood release manager here.

Just wanted to bring some clarity around what the release schedule timeline will before the 21.05 release. This is heavily based upon RFC 85 which aims at decreasing the amount of potential breakages going into a release by limiting changes to staging to just minor bumps and bugfixes. Large breaking changes right before release has caused many issues in the past, and they should be avoided.

For simplicity, I broke out the events into two tables, one for the release centric events, and one for “restricting” breaking changes done to the staging branch.

Date Release Event
May 7th Zero Hydra Failures (ZHF) Begins, targets master
May 21st Branch-off, move to “backport” ZHF workflow targeting release-21.05
May 28th 21.05 Release, ZHF Ends
Date Staging / Staging-next Event
April 16th Breaking changes to release critical packages are not allowed to be merged
April 30th Breaking changes to any package which needs to target staging is disallowed
May 6th Merge staging-next PR, begin ZHF next day
May 14th Merge first stable staging-next PR*
May 14th Start second stable staging-next PR*
May 14th Open staging up to any breaking changes, these changes will not land in the release
May 21st Merge second stabilizing staging-next PR
May 21st Branch-off, release development will follow release-21.05
May 28th 21.05 Release, ZHF Ends

*: stable staging-next PR just means a staging-next PR whose changes will be included in the release.
ZHF: Zero Hydra Failures, a period in time in which we try to fix as many failing builds and tests as reported by Hydra.


Does this mean we don’t have to backport PRs for the first two weeks of ZHF?

  • Yes, part of the motivation was to make ZHF less tedious for both contributors, and reviewers. The first two weeks usually takes care of most of the “low hanging fruit” for fixing builds and tests, only a minority of fixes will need to be backported after the branch-off.

Will my contributions to master be affected?

  • No, as long as you are “green to green” (package and downstream packages still work) or “red to green” (fixed a package or downstream issue), you will not see any impedance. This is largely the case for most contributions targeting master already.

Why limit breaking changes to only staging?

  • Staging remains to be the “Achilles’ Heel”(weakspot) of nixpkgs. Changes which target staging generally affect several hundred to thousands of packages. Trying to capture these effects is difficult for any distribution; and generally handled by seldomly updating these types of packages (e.g. Debian 10 vs Debian 11). For the stable release, I wanted to mitigate the number of “new failures” which may had already been fixed in previous ZHF PRs.
  • PRs targeting master are essentially “small enough” in scope that the changes can be mostly captured, thus these PRs do not need to be restricted and likely trying to restrict them in some manner will likely cause more issues than it will solve.

Can I add a new version of a package that would normally warrant a staging PR?

  • Yes. For example, if gcc11 were to be released, you will be able to add gcc11 and gcc11Stdenv into nixpkgs; however, you would not be able to bump the default stdenv or gcc, as this would cause a mass rebuild and likely introduce many regressions. You could also view the PR to add gcc11 as a PR which would target master, therefore doesn’t warrant any breaking changes restrictions.