# Releases

## Release process

Going through an example of releasing NixOS 17.09:

### One month before the beta

- Send an email to the nix-devel mailinglist as a warning about upcoming beta "feature freeze" in a month.

- 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.

### At beta release time

- Create an issue for tracking Zero Hydra Failures progress. ZHF is an effort to get build failures down to zero.

- `git tag -a -s -m "Release 17.09-beta" 17.09-beta && git push origin 17.09-beta`

- From the master branch run `git checkout -b release-17.09`.

- Make sure a channel is created at http://nixos.org/channels/.

- Bump the `system.defaultChannel` attribute in `nixos/modules/misc/version.nix`

- Update `versionSuffix` in `nixos/release.nix`, use `git log --format=%an|wc -l` to get the commit count

- `echo -n "18.03" > .version` on master.

- Pick a new name for the unstable branch.

- Create a new release notes file for the upcoming release + 1, in this case `rl-1803.xml`.

- Create two Hydra jobsets: release-17.09 and release-17.09-small with `stableBranch` set to false.

- 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

- Edit changelog at `nixos/doc/manual/release-notes/rl-1709.xml` (double check desktop versions are noted)

  - Get all new NixOS modules `git diff release-17.03..release-17.09 nixos/modules/module-list.nix|grep ^+`

  - Note systemd, kernel, glibc and Nix upgrades.

### 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

- `git tag -s -a -m "Release 15.09" 15.09`

- Update "Chapter 4. Upgrading NixOS" section of the manual to match new stable release version.

- Update the `NIXOS_SERIES` in the nixos-homepage repository.

- Get number of commits for the release: `git log release-14.04..release-14.12 --format=%an|wc -l`

- Commits by contributor: `git log release-14.04..release-14.12 --format=%an|sort|uniq -c|sort -rn`

- Create a new topic on the Discourse instance to announce the release with the above information. Best to check how previous email 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

## Release schedule

Date | Event
--- | ---
2016-07-25 | Send email to nix-dev about upcoming branch-off
2016-09-01 | `release-16.09` branch and corresponding jobsets are created, change freeze
2016-09-30 | NixOS 16.09 released