Nixpkgs: Document release process for NixOS

[domenkozar]

In order to be better organized and ready for release, we should document what needs to be done before the release together with an informative schedule.

A month before the release

• send a warning email to nix-dev and talk to Eelco/others what should be part of the release.

  At branch off time

• Rename rl-unstable.xml -> rl-1509.xml

• create the branch
• git tag -a -m "Release 15.09-beta" 15.09-branch-off && git push --tags
  
  
  
  • Note: the the commit that should be tagged: git merge-base master release-15.09.
  
  
• hard lock the branch on github (so people can't force push)
• bump system.defaultChannel attribute in nixos/modules/misc/version.nix, see https://github.com/NixOS/nixpkgs/compare/bdf161ed8d21...6b63c4616790
• update versionSuffix in nixos/release.nix, see https://github.com/NixOS/nixpkgs/compare/bdf161ed8d21...6b63c4616790 (git log --format=%an|wc -l to get commit count)
• echo -n "16.09" > .version in master
• pick a new name for unstable branch, see https://github.com/NixOS/nixpkgs/commit/b8a4095003e27659092892a4708bb3698231a842
• Create an issue for tracking ZHF progress
• check http://monitor.nixos.org/vulnerable for vulnerable packages

• create two Hydra jobsets (release and release-small)

  Before release

• generate nixops images for this release (EC2/GCE/VB)

• release nixops (currently only Rob can do that)
• release nix (currently only Eelco can do that), make sure fallback is updated https://github.com/NixOS/nixpkgs/commit/53710c752a85f00658882531bc90a23a3d1287e4

• edit changelog at nixos/doc/manual/release-notes/rl-1509.xml (double check desktop versions are noted)

  • get all new NixOS modules git di release-14.12..release-15.09 nixos/modules/module-list.nix|grep ^+
  • note systemd and Nix updates
    

    At release time

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

• update https://nixos.org/wiki/Template:Nixos_stable_channel
• update http://nixos.org/nixos/download.html
• update http://nixos.org/nixos/manual/
• 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

[wmertens]

Can we already create the branch and then stabilize it? There's no reason to hold up development on master...

[vcunat]

Yes, exactly. Instead of postponing all destabilizing updates for a week or two, it is much better to just branch release-14.10 earlier. Another alternative that we newly have would be to put destabilizing changes into staging instead, which is anyway IMHO the correct place for them (especially if they cause lots of rebuilds).

[domenkozar]

We also need to document the release schedule for each release.

[bjornfor]

IMHO, we should also create git tags: https://github.com/NixOS/nixpkgs/issues/9009

[domenkozar]

@bjornfor https://github.com/NixOS/nixpkgs/releases/tag/15.09

[domenkozar]

This should be ready now so it's included in the manual.

[bjornfor]

@domenkozar: Thanks for the tag :-D

[domenkozar]

Another document we need to pull together: https://www.freebsd.org/releases/10.3R/schedule.html

[domenkozar]

Managed to branch-off 16.03 in time.

[vcunat]

You seem to have forgotten to push 16.03-beta tag, so I did that now. (EDIT: I think the rest of the list was done, perhaps except for the ZHF issue.)

[domenkozar]

Thanks. I always forget tags need to be pushed explicitly.

[domenkozar]

Improvement for next release: use 16.09-beta for version name until the final release.

The downside is, folks have to change the channel first for the beta, then for the final release. (currently @edolstra just renamed the channel which gives some unfortunate consequences and inconsistencies).

[vcunat]

It would seem better to me to call the channel the same all the time, just as it's still the same branch. The beta/stable/... status isn't really black or white and seems better handled by _announcing_ we consider it stable/released and changing the default download links. (But the naming is an unimportant nitpick to me personally.)

[wmertens]

What @vcunat proposes is the same as what Debian has been doing with great success, but they also have aliases for the channels (stable, testing and unstable iirc). Might we do the same?

[vcunat]

We have nixpkgs-unstable and nixos-unstable channels. I can't see what other alias(es) might be useful, as I don't think many people want the systems to auto-upgrade to a higher release.