From dab442f847affa869a67ce56a15734022573a2a6 Mon Sep 17 00:00:00 2001 From: ryan Date: Sun, 14 Apr 2024 18:47:41 -0400 Subject: [PATCH] MAINTENANCE: Improve wording about merging release --- MAINTENANCE.md | 32 +++++++++++++++++--------------- 1 file changed, 17 insertions(+), 15 deletions(-) diff --git a/MAINTENANCE.md b/MAINTENANCE.md index defb973..857e369 100644 --- a/MAINTENANCE.md +++ b/MAINTENANCE.md @@ -1,11 +1,12 @@ ## Pull Requests Pull requests for every change should follow the given flow: -`pull-request-branch -> staging -> current-release-branch -> main`. Making a -commit short-cut the staging or the release branch removes the ability to track -who approves contributions and when those contributions has been approved. Even -if a patch is necessary for a release, it _must_ flow from a PR, to staging, to -the release branch. +`pull-request-branch -> staging -> current-release-branch -> staging -> main`. +Making a commit short-cut the staging or the release branch removes the ability +to track who approves contributions and when those contributions has been +approved. If a patch is necessary for a release, it should flow from a PR, to +staging, to the release branch. The release branch should not contain any +changes (ignoring `digests.txt` and signatures) that do not exist in `staging`. Pull requests should be merged using a signed merge commit. To configure your Git porcelain to always use merge commits, run `git config merge.ff false`. To @@ -16,18 +17,19 @@ commit.gpgsign true`. Release branches take the format `YYYY.MM.release`. A release should include a PR to staging to introduce a bump to `digests.txt`, creating the release -branch. Once the branch is created, other users can begin reproducing. The -release engineer should run `make sign` to ensure a signature exists for every -package. +branch. Once the branch is created, other maintainers should begin reproducing. +The release engineer should run `make sign` to ensure a signature exists for +every package included in the release. In the Git forge UI, the release pull request should target the `main` branch, -to provide a summary of all changes since the last major code freeze. +to provide a summary of all changes since the latest release. Any commits required once the branch is created, but before the release is -published, should flow from a PR (if push access is not given) to the release -branch. +published, should flow from a PR (if push access to the release branch is not +given) to staging, where the release branch can then rebase on staging. -Once a release is published, the branch should perform a signed merge commit -into main. Any further pull requests to the branch (which may be published -after release, if strictly necessary) can target the release branch directory, -and the release branch will live on its own. +Once a release is published, the release branch should perform a signed merge +commit into staging, followed by a signed merge commit from staging to main. +Any further pull requests to the branch after the series of releases is done +(which may be published after release, if strictly necessary) can target the +release branch, and the release branch will live on its own.