branch-off: modify based on branch-off of 25.11 #107
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change | ||||
|---|---|---|---|---|---|---|
|
|
@@ -14,30 +14,54 @@ before release to create the necessary Hydra Jobsets. You can link them this sec | |||||
| - [https://hydra.nixos.org/project/nixos](https://hydra.nixos.org/project/nixos) | ||||||
| - release-24.05 | ||||||
| - release-24.05-small | ||||||
| - staging-next-24.05-small | ||||||
| - [https://hydra.nixos.org/project/nixpkgs](https://hydra.nixos.org/project/nixpkgs) | ||||||
| - nixpkgs-24.05-darwin | ||||||
| - staging-next-24.05 | ||||||
| - staging-24.05 | ||||||
|
|
||||||
| The easiest way to create the new jobsets is to clone the ones from the previous release and rewrite the version number. | ||||||
|
|
||||||
| Example configuration: [nixos:release-25.11](https://hydra.nixos.org/jobset/nixos/release-25.11#tabs-configuration) | ||||||
|
|
||||||
| |Field|Value| | ||||||
| |-|-| | ||||||
| |State|Enabled| | ||||||
| |Description|NixOS 24.05 release branch| | ||||||
| |Nix expression|`nixos/release-combined.nix` in input `nixpkgs`| | ||||||
| |Check interval|151200| | ||||||
| |Scheduling shares|5000000 (8.32% out of 60071636 shares)| | ||||||
| |Enable Dynamic RunCommand Hooks:|No (not enabled by server)| | ||||||
| |Number of evaluations to keep|1| | ||||||
|
|
||||||
| ### Inputs for `nixos/release-24.05`, `nixos/release-24.05-small`: | ||||||
|
|
||||||
| |Input name|Type|Values| | ||||||
| |-|-|-| | ||||||
| |`nixpkgs`|Git checkout|`https://github.com/NixOS/nixpkgs.git release-24.05`| | ||||||
| |`stableBranch`|Boolean|`false`| | ||||||
| |`supportedSystems`|Nix expression|`[ "x86_64-linux" "aarch64-linux" ]`| | ||||||
|
|
||||||
| `stableBranch` influences the `versionSuffix` in NixOS and the channel tarball. | ||||||
|
|
||||||
| - `true` leads to `24.05.1234.0abs3fe` | ||||||
| - `false` leads to `24.05pre1234.0abs3fe` | ||||||
|
|
||||||
| Note that changing this leads to a rebuild of most NixOS tests! | ||||||
|
|
||||||
| ### Inputs for `nixpkgs/nixpkgs-24.05-darwin`: | ||||||
|
|
||||||
| |Input name|Type|Values| | ||||||
| |-|-|-| | ||||||
| |`nixpkgs`|Git checkout|`https://github.com/NixOS/nixpkgs.git release-24.05`| | ||||||
| |`officialRelease`|Boolean|`false`| | ||||||
| |`supportedSystems`|Nix expression|`[ "x86_64-darwin" "aarch64-darwin" ]`| | ||||||
|
|
||||||
| `officialRelease` influences the `versionSuffix` of the release tarball | ||||||
|
|
||||||
| - `true` leads to `24.05.1234.0abs3fe` | ||||||
| - `false` leads to `24.05pre1234.0abs3fe` | ||||||
|
|
||||||
| ## Nixpkgs branch protection ruleset | ||||||
|
|
||||||
| The same as for the jobsets applies to Nixpkgs branch protection rulesets, which can be updated by NixOS org owners in advance. | ||||||
|
|
@@ -48,7 +72,7 @@ New release branches should be added to the `includes` list in: | |||||
|
|
||||||
| ## Actual branch-off | ||||||
|
|
||||||
| Set NEWVER to the new release version (i.e. the version you release): | ||||||
|
|
||||||
| ```bash | ||||||
| export NEWVER=24.05 | ||||||
|
|
@@ -72,17 +96,27 @@ Pull in the final changes before performing the actual branch-off. | |||||
|
|
||||||
| Update metadata on the release branch, create its staging branches and tag the release. | ||||||
|
|
||||||
| 1. Update the `system.defaultChannel` option default in [`nixos/modules/config/nix-channel.nix`](https://github.com/NixOS/nixpkgs/commit/3c80acabe4eef35d8662733c7e058907fa33a65d#diff-14008678e5ceeef1edd491de85bca2bded89daea16793fe10c4eb724097b7f12) | ||||||
|
|
||||||
| 1. Update the `versionSuffix` attribute in [`nixos/release.nix`](https://github.com/NixOS/nixpkgs/commit/3c80acabe4eef35d8662733c7e058907fa33a65d#diff-20da30ee012d7d87842fb7953237870493c5497c995cba1e6f6c3aa9268398ff) | ||||||
|
|
||||||
| To get the commit count, use the following command: | ||||||
|
|
||||||
| ```bash | ||||||
| git rev-list --count release-$NEWVER | ||||||
| ``` | ||||||
|
|
||||||
| 1. Add `SUPPORT_END = "YYYY-MM-DD";` to `osReleaseContents` in [`nixos/modules/misc/version.nix`](https://github.com/NixOS/nixpkgs/commit/3c80acabe4eef35d8662733c7e058907fa33a65d#diff-b3379a98640b35a5fe4b046150cd2df1639995edf231d18bbad832be6a70b45f). | ||||||
|
|
||||||
| 1. Run treefmt | ||||||
| ```bash | ||||||
| nix-shell --run treefmt | ||||||
| ``` | ||||||
|
|
||||||
| 1. Test that the `tested` "job" still evals | ||||||
| ```bash | ||||||
| nix eval -f nixos/release-combined.nix tested | ||||||
| ``` | ||||||
|
|
||||||
| 1. Commit the changes from the previous steps | ||||||
|
|
||||||
|
|
@@ -102,8 +136,9 @@ Update metadata on the release branch, create its staging branches and tag the r | |||||
| 1. Tag the release and push everything | ||||||
|
|
||||||
| ```bash | ||||||
| git switch release-$NEWVER | ||||||
| git tag --annotate --message="Release $NEWVER-beta" $NEWVER-beta | ||||||
| git push upstream release-$NEWVER $NEWVER-beta staging-$NEWVER staging-next-$NEWVER | ||||||
| ``` | ||||||
|
|
||||||
| 1. Create jobsets on hydra by contacting the infrastructure team and start the evaluation on all new jobsets. | ||||||
|
|
@@ -114,49 +149,90 @@ Update metadata on the release branch, create its staging branches and tag the r | |||||
| git switch master | ||||||
| ``` | ||||||
|
|
||||||
| 1. Create the backport [label](https://github.com/NixOS/nixpkgs/labels) for the new release branch: | ||||||
| - `backport release-24.05` | ||||||
|
|
||||||
| Use the description `Backport PR automatically` and the color value `#0fafaa` | ||||||
|
|
||||||
| ### Back on the master branch | ||||||
|
|
||||||
| Now we prepare the master branch for the next release after this one. We do this in two steps, error-prone changes thorugh a PR and direct to allow for proper tagging. | ||||||
|
|
||||||
| Set NEXTVER to the release number after the one you released (i.e. when you release 24.05, `NEXTVER=24.11`). | ||||||
|
|
||||||
| ```bash | ||||||
| export NEXTVER=24.11 | ||||||
| ``` | ||||||
|
|
||||||
| #### PR changes 1 | ||||||
|
|
||||||
| 1. Checkout a branch you want for the first PR, e.g. | ||||||
|
|
||||||
| ```bash | ||||||
| git switch -c rm-branchoff-documentation-changes | ||||||
| ``` | ||||||
|
|
||||||
| 1. Add the release name to [`nixos/doc/manual/release-notes/rl-$NEXTVER.section.md`](https://github.com/NixOS/nixpkgs/commit/bf470a4fddca6315d1b7c256a873c90f755b02d9#diff-417feb28ebc7ab0109746fef515d6cccdcd5af5c7386e1ce0b186db9b8e5677b), [`doc/release-notes/rl-2411.section.md`](https://github.com/NixOS/nixpkgs/commit/bf470a4fddca6315d1b7c256a873c90f755b02d9#diff-c5ba8855198f95e7fdb39bcd1106bb29c96b85c14bdfc4030b235a02806bf9b3) | ||||||
|
Member
There was a problem hiding this comment. If we use a variable, we probably should do it on both of them and not just one. Note that they have the
Suggested change
|
||||||
|
|
||||||
| 1. Include `rl-$NEXTVER.section.md` in [`nixos/doc/manual/release-notes/release-notes.md`](https://github.com/NixOS/nixpkgs/commit/bf470a4fddca6315d1b7c256a873c90f755b02d9#diff-9b75bf997f6c13cb4a15145ef9e758a28addeeff4a3a5cb893a5c23a976b3a1a), [`doc/release-notes/release-notes.md`](https://github.com/NixOS/nixpkgs/commit/bf470a4fddca6315d1b7c256a873c90f755b02d9#diff-89abd55b6169384ba08083097a7ac5f5c30ea35d432a0ba2d1a76887f50a4f49) | ||||||
|
|
||||||
| 1. Update [`nixos/manual/doc/redirects.json`](https://github.com/NixOS/nixpkgs/commit/bf470a4fddca6315d1b7c256a873c90f755b02d9#diff-8e9034e569678f9c67bf82087ff7dced3b18de5491707988a43fb8979a82794f), [`doc/redirects.json`](https://github.com/NixOS/nixpkgs/commit/bf470a4fddca6315d1b7c256a873c90f755b02d9#diff-9499ad98fd024845445ff2f32b424d29f632932b4bbe15dfd9d0f447890bbae6) and to include the new sections. | ||||||
|
|
||||||
| 1. Go through `.github/ISSUE_TEMPLATE`, and edit them to include the new version as beta. | ||||||
|
|
||||||
| Example [25.11](https://github.com/NixOS/nixpkgs/commit/c69a76cf803096fb8d1b3732fea57d69d6d301f1) | ||||||
|
|
||||||
| 1. Commit the changes and create a PR. | ||||||
| Wait for the CI to finish and merge. | ||||||
|
|
||||||
| #### PR changes 2 | ||||||
|
|
||||||
| You can create this PR while waiting for the CI of the first one. | ||||||
|
|
||||||
| 1. Checkout a branch you want for the second PR, e.g. | ||||||
|
|
||||||
| ```bash | ||||||
| git switch -c rm-branchoff-ci-changes | ||||||
| ``` | ||||||
|
|
||||||
| 1. Update [.github/workflows/periodic-merge-24h.yml](https://github.com/NixOS/nixpkgs/commit/bf470a4fddca6315d1b7c256a873c90f755b02d9#diff-a4f6ea695ede268916c760fe782e9645a8cab5b27747e4baa994bf59f3e4e07b) so that | ||||||
| - `release-$NEWVER` (instead of `master`) gets merged into `staging-next-$NEWVER` | ||||||
|
|
||||||
| 1. Update [.github/labeler-no-sync.yml](https://github.com/NixOS/nixpkgs/commit/fb0fb7420fcafaaced083c6767da35617f2837f3) so that it includes `backport release-25.11`. | ||||||
|
Contributor
There was a problem hiding this comment. Thanks for adding this. I went through the docs, but couldn't find the second part of this: After branch-off, the new release branch must be changed and the existing entry for the backport label must be removed from that file. The related PR was this: NixOS/nixpkgs#464874 (is there already a step with a PR towards the release branch after its creation?)
Member
Author
There was a problem hiding this comment. Ah, I didn't know that. I will add that later
Member
Author
There was a problem hiding this comment. Is this required to not create a loop
Or otherwise, why can't we just remove
Contributor
There was a problem hiding this comment. Yes, we want to backport the CI changes to both branches straight from master - and the additional backport label on the backport PR itself creates a useless PR. I tried doing "chained backports" instead, which would only require changing the master branch after branch-off, but this quickly became very annoying to deal with. |
||||||
|
|
||||||
| #### Direct changes | ||||||
|
|
||||||
| These changes should be done when the two PRs are already merged. | ||||||
|
|
||||||
| 1. Switch back to the `master` branch | ||||||
| ```bash | ||||||
| git switch master | ||||||
| ``` | ||||||
|
|
||||||
| 1. Update the branch to get the changes from the two PRs | ||||||
| ```bash | ||||||
| git pull | ||||||
| ``` | ||||||
|
|
||||||
| 1. Increment the [`lib/.version`](https://github.com/NixOS/nixpkgs/commit/01268fda85b7eee4e462c873d8654f975067731f#diff-2bc0e46110b507d6d5a344264ef15adaR1) | ||||||
| file. This file must **not** end with a new line! | ||||||
|
|
||||||
| ```bash | ||||||
| # The release after $NEWVER (24.05 -> 24.11) | ||||||
| echo -n "$NEXTVER" > lib/.version | ||||||
| ```` | ||||||
|
|
||||||
| 1. Update the `codeName` attribute in [`lib/trivial.nix`](https://github.com/NixOS/nixpkgs/commit/2c28f1de7cdc10be556d2106108411dd2482794b#diff-29c71aa8261b14b1cad6e6fa28486fed7295050db4eeb32ba205672ba91d40e1) | ||||||
| This will be the name for the next release. | ||||||
|
|
||||||
| 1. Commit the changes as `$NEXTVER is <codeName>`([25.11 example](https://github.com/NixOS/nixpkgs/commit/2493002b10ccef0880f72d7720538f91fb4f7434)) | ||||||
|
Member
There was a problem hiding this comment. Maybe also do treefmt and eval here before committing. |
||||||
|
|
||||||
| 1. Tag the master branch, so that `git describe` shows the new version as the base for commits. | ||||||
|
|
||||||
| ```bash | ||||||
| git tag --annotate $NEXTVER-pre | ||||||
| git push upstream master $NEXTVER-pre | ||||||
| git describe HEAD # should yield $NEXTVER-pre | ||||||
| ``` | ||||||
|
|
||||||
| ### And afterwards | ||||||
|
|
@@ -169,24 +245,14 @@ Now that everything on git is done, we are still missing the channels. | |||||
|
|
||||||
| Example: [22.11](https://github.com/NixOS/infra/commit/9a0b3674a11b445c973334c78e8ca0eda36775e4) | ||||||
|
|
||||||
| 1. Update the ZHF issue, that now that the branch-off has been performed, fixes have to be backported. | ||||||
| Examples: [22.05](https://github.com/NixOS/nixpkgs/issues/172160#issuecomment-1135112918) | ||||||
|
|
||||||
| ### Once the channel is available | ||||||
|
|
||||||
| The following steps should be done after the channels have become available on [channels.nixos.org](https://channels.nixos.org). | ||||||
|
|
||||||
| 1. Update the flake input on the `nixos-search` repository by running [the update-flake-lock](https://github.com/NixOS/nixos-search/actions/workflows/update-flake-lock.yml) and merging the new created PR afterwards. | ||||||
|
|
||||||
| 1. Give the [Marketing team](https://matrix.to/#/#marketing:nixos.org) a heads-up about the upcoming release | ||||||
|
|
||||||
|
|
||||||
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's possible to add a note somewhere that it seems easiest to just clone the previous release's jobsets (by a single click per jobset) and just rewrite the version number on a few places.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I added that. I must say that I'm not that happy about this whole section and I think we can remove much of that. Still it would be good to document a default somewhere.