Co-Authored-By: Robert Hensing <robert@roberthensing.nl Co-authored-by: Dan Baker <daniel.n.baker@gmail.com>
6.8 KiB
Nix release process
Release artifacts
The release process is intended to create the following for each release:
-
A Git tag
-
Binary tarballs in https://releases.nixos.org/?prefix=nix/
-
Docker images
-
Closures in https://cache.nixos.org
-
(Optionally) Updated
fallback-paths.nix
in Nixpkgs -
An updated manual on https://nix.dev/manual/nix/latest/
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 rungit pull
. -
Compile the release notes by running
$ export VERSION=X.YY $ git checkout -b release-notes $ ./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.
-
Run
maintainers/release-credits
to make sure the credits script works and produces a sensible output. Some emails might not automatically map to a GitHub handle. -
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 setsofficialRelease = true
inflake.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
inhttps://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 thelatest-release
branch to be force-updated. This is used by thenixos.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 preventsnixos.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.
Security releases
See also the instructions for handling security reports.
Once a security fix is ready for merging:
-
Summarize all past communication in the report.
-
Request a CVE in the GitHub security advisory for the security fix.
-
Notify all collaborators on the advisory with a timeline for the release.
-
Merge the fix. Publish the advisory.
-
Make point releases for all affected versions.
-
Update the affected Nix releases in Nixpkgs to the patched version.
For each Nix release, change the
version =
strings and runnix-build -A nixVersions.nix_<major>_<minor>
to get the correct hash for the
hash =
field. -
Once the release is built by Hydra, update fallback paths.
For the Nix release
${version}
shipped with Nixpkgs, run:curl https://releases.nixos.org/nix/nix-${version}/fallback-paths.nix > nixos/modules/installer/tools/nix-fallback-paths.nix
Starting with Nixpkgs 24.11, there is an automatic check that fallback paths with Nix binaries match the Nix release shipped with Nixpkgs.
-
Backport the updates to the two most recent stable releases of Nixpkgs.
Add
backport release-<version>
labels, which will trigger GitHub Actions to attempt automatic backports. -
Once the pull request against
master
lands onnixpkgs-unstable
, post a Discourse announcement with- Links to the CVE and GitHub security advisory
- A description of the vulnerability and its fix
- Credits to the reporters of the vulnerability and contributors of the fix
- A list of affected and patched Nix releases
- Instructions for updating
- A link to the pull request tracker to follow when the patched Nix versions will appear on the various release channels
Check past announcements for reference.