nordic-dev.net/nix
nordic-dev.net/nix
2
0
Fork 0
mirror of https://github.com/NixOS/nix.git synced 2024-11-22 14:52:55 +00:00
Code Issues Packages Projects Releases Wiki Activity
6971c4adc0
nix/maintainers/release-process.md
Robert Hensing 6971c4adc0 maintainers/release-notes <- scripts/release-notes
2023-11-24 16:53:33 +01:00

4.6 KiB
Raw Blame History

Nix release process

Release artifacts

The release process is intended to create the following for each release:

Creating a new release from the master branch

  • Make sure that the Hydra master jobset succeeds.

  • In a checkout of the Nix repo, make sure you're on master and run git pull.

  • Compile the release notes by running

    $ git checkout -b release-notes
$ VERSION=X.YY ./maintainers/release-notes

    where X.YY is without the patch level, e.g. 2.12 rather than 2.12.0.

    A commit is created.

  • Proof-read / edit / rearrange the release notes if needed. Breaking changes and highlights should go to the top.

  • Push.

    $ git push --set-upstream $REMOTE release-notes

  • Create a PR for release-notes.

  • Wait for the PR to be merged.

  • Create a branch for the release:

    $ git checkout master
$ git pull
$ git checkout -b $VERSION-maintenance

  • Mark the release as official:

    $ sed -e 's/officialRelease = false;/officialRelease = true;/' -i flake.nix

    This removes the link to rl-next.md from the manual and sets officialRelease = true in flake.nix.

  • Commit

  • Push the release branch:

    $ git push --set-upstream origin $VERSION-maintenance

  • Create a jobset for the release branch on Hydra as follows:

    • Go to the jobset of the previous release (e.g. https://hydra.nixos.org/jobset/nix/maintenance-2.11).

    • Select Actions -> Clone this jobset.

    • Set identifier to maintenance-$VERSION.

    • Set description to $VERSION release branch.

    • Set flake URL to github:NixOS/nix/$VERSION-maintenance.

    • Hit Create jobset.

  • Wait for the new jobset to evaluate and build. If impatient, go to the evaluation and select Actions -> Bump builds to front of queue.

  • When the jobset evaluation has succeeded building, take note of the evaluation ID (e.g. 1780832 in https://hydra.nixos.org/eval/1780832).

  • Tag the release and upload the release artifacts to releases.nixos.org and Docker Hub:

    $ IS_LATEST=1 ./maintainers/upload-release.pl <EVAL-ID>

    Note: IS_LATEST=1 causes the latest-release branch to be force-updated. This is used by the nixos.org website to get the latest Nix manual.

    TODO: This script requires the right AWS credentials. Document.

    TODO: This script currently requires a /home/eelco/Dev/nix-pristine.

    TODO: trigger nixos.org netlify: https://docs.netlify.com/configure-builds/build-hooks/

  • Prepare for the next point release by editing .version to e.g.

    $ echo 2.12.1 > .version
$ git commit -a -m 'Bump version'
$ git push

    Commit and push this to the maintenance branch.

  • Bump the version of master:

    $ git checkout master
$ git pull
$ NEW_VERSION=2.13.0
$ echo $NEW_VERSION > .version
$ git checkout -b bump-$NEW_VERSION
$ git commit -a -m 'Bump version'
$ git push --set-upstream origin bump-$NEW_VERSION

    Make a pull request and auto-merge it.

  • Create a milestone for the next release, move all unresolved issues from the previous milestone, and close the previous milestone. Set the date for the next milestone 6 weeks from now.

  • Create a backport label.

  • Post an announcement on Discourse, including the contents of rl-$VERSION.md.

Creating a point release

  • Checkout.

    $ git checkout XX.YY-maintenance

  • Determine the next patch version.

    $ export VERSION=XX.YY.ZZ

  • Update release notes.

    $ ./maintainers/release-notes

  • Push.

    $ git push

  • Wait for the desired evaluation of the maintenance jobset to finish building.

  • Run

    $ IS_LATEST=1 ./maintainers/upload-release.pl <EVAL-ID>

    Omit IS_LATEST=1 when creating a point release that is not on the most recent stable branch. This prevents nixos.org to going back to an older release.

  • Bump the version number of the release branch as above (e.g. to 2.12.2).

Recovering from mistakes

upload-release.pl should be idempotent. For instance a wrong IS_LATEST value can be fixed that way, by running the script on the actual latest release.