diff options
author | Janne Heß <dasJ@users.noreply.github.com> | 2022-10-21 22:58:33 +0200 |
---|---|---|
committer | GitHub <noreply@github.com> | 2022-10-21 22:58:33 +0200 |
commit | 1b768f41e9ff7c4c4701811a4a2b22601b55c6f7 (patch) | |
tree | d0ea9a9e7a651ab3507d2afd8bcde411aa3a4799 /doc | |
parent | e902243667584daf6e558bafd3bde3ab370af2c4 (diff) | |
parent | dabac4bf0c5eefbb07402189d9ba6efce3ff7b34 (diff) |
Merge pull request #173506 from helsinki-systems/feat/document-no-breaking-commits
doc: Document that the staging branches may be restricted
Diffstat (limited to 'doc')
-rw-r--r-- | doc/contributing/submitting-changes.chapter.md | 4 |
1 files changed, 4 insertions, 0 deletions
diff --git a/doc/contributing/submitting-changes.chapter.md b/doc/contributing/submitting-changes.chapter.md index 8e8ca8e19ad6..e80a264dea68 100644 --- a/doc/contributing/submitting-changes.chapter.md +++ b/doc/contributing/submitting-changes.chapter.md @@ -244,12 +244,16 @@ The `master` branch is the main development branch. It should only see non-break The `staging` branch is a development branch where mass-rebuilds go. Mass rebuilds are commits that cause rebuilds for many packages, like more than 500 (or perhaps, if it's 'light' packages, 1000). It should only see non-breaking mass-rebuild commits. That means it is not to be used for testing, and changes must have been well tested already. If the branch is already in a broken state, please refrain from adding extra new breakages. +During the process of a releasing a new NixOS version, this branch or the release-critical packages can be restricted to non-breaking changes. + ### Staging-next branch {#submitting-changes-staging-next-branch} The `staging-next` branch is for stabilizing mass-rebuilds submitted to the `staging` branch prior to merging them into `master`. Mass-rebuilds must go via the `staging` branch. It must only see non-breaking commits that are fixing issues blocking it from being merged into the `master` branch. If the branch is already in a broken state, please refrain from adding extra new breakages. Stabilize it for a few days and then merge into master. +During the process of a releasing a new NixOS version, this branch or the release-critical packages can be restricted to non-breaking changes. + ### Stable release branches {#submitting-changes-stable-release-branches} The same staging workflow applies to stable release branches, but the main branch is called `release-*` instead of `master`. |