Releases

Release process Going through an example of releasing NixOS 19.09:

One month before the beta Create an announcement on Discourse as a warning about upcoming beta feature freeze in a month. See this post as an example. Discuss with Eelco Dolstra and the community (via IRC, ML) about what will reach the deadline. Any issue or Pull Request targeting the release should be included in the release milestone. Remove attributes that we know we will not be able to support, especially if there is a stable alternative. E.g. Check that our Linux kernels’ projected end-of-life are after our release projected end-of-life.

At beta release time From the master branch run: git checkout -b release-19.09 Bump the system.defaultChannel attribute in nixos/modules/misc/version.nix Update versionSuffix in nixos/release.nix To get the commit count, use the following command: git rev-list --count release-19.09 Edit changelog at nixos/doc/manual/release-notes/rl-1909.xml. Get all new NixOS modules: git diff release-19.03..release-19.09 nixos/modules/module-list.nix | grep ^+ Note systemd, kernel, glibc, desktop environment, and Nix upgrades. Tag the release: git tag --annotate --message="Release 19.09-beta" 19.09-beta git push upstream 19.09-beta On the master branch, increment the .version file echo -n "20.03" > .version Update codeName in lib/trivial.nix This will be the name for the next release. Create a new release notes file for the upcoming release + 1, in our case this is rl-2003.xml. Contact the infrastructure team to create the necessary Hydra Jobsets. Create a channel at https://nixos.org/channels by creating a PR to nixos-org-configurations, changing channels.nix Get all Hydra jobsets for the release to have their first evaluation. Create an issue for tracking Zero Hydra Failures progress. ZHF is an effort to get build failures down to zero.

During Beta Monitor the master branch for bugfixes and minor updates and cherry-pick them to the release branch.

Before the final release Re-check that the release notes are complete. Release Nix (currently only Eelco Dolstra can do that). Make sure fallback is updated. Update README.md with new stable NixOS version information. Change stableBranch to true in Hydra and wait for the channel to update.

At final release time Update section of the manual to match new stable release version. Update rl-1909.xml with the release date. Tag the final release git tag --annotate --message="Release 19.09" 19.09 git push upstream 19.09 Update nixos-homepage for the release. Update NIXOS_SERIES in the Makefile. Update nixos-release.tt with the new NixOS version. Update the flake.nix input released-nixpkgs to 19.09. Run ./update.sh (this updates flake.lock to updated channel). Add a compressed version of the NixOS logo for 19.09. Compose a news item for the website RSS feed. Create a new topic on the Discourse instance to announce the release. You should include the following information: Number of commits for the release: bash git log release-19.03..release-19.09 --format=%an | wc -l Commits by contributor: git shortlog --summary --numbered release-19.03..release-19.09 Best to check how the previous post was formulated to see what needs to be included.

Release Management Team For each release there are two release managers. After each release the release manager having managed two releases steps down and the release management team of the last release appoints a new release manager. This makes sure a release management team always consists of one release manager who already has managed one release and one release manager being introduced to their role, making it easier to pass on knowledge and experience. Release managers for the current NixOS release are tracked by GitHub team @NixOS/nixos-release-managers. A release manager’s role and responsibilities are: manage the release process start discussions about features and changes for a given release create a roadmap release in cooperation with Eelco Dolstra decide which bug fixes, features, etc… get backported after a release