ryan-distrust.co/stagex
1
0
Fork 0
Code Issues 1 Pull requests Projects Releases Packages Wiki Activity Actions

MAINTENANCE: Improve wording about merging release

Browse source
This commit is contained in:
ryan 2024-04-14 18:47:41 -04:00
parent 068c0eda6e
commit dab442f847
No known key found for this signature in database
GPG key ID: 8E401478A3FBEF72
1 changed files with 17 additions and 15 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

32
MAINTENANCE.md
View file

@ -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.