jimeh/common-flow
1
0
Fork 0
mirror of https://github.com/jimeh/common-flow.git synced 2026-02-19 01:16:40 +00:00
Code Issues Packages Projects Releases Wiki Activity

feat(releases): allow release tags on merge commits for PR-based releases

Browse Source 
Add support for release pull requests as an optional workflow. When
usingrelease PRs, the release tag SHOULD be placed on the resulting
merge commitrather than the version bump commit itself.

Changes:

- Add new item 7.5 defining release pull requests
- Update item 7.4 to reference the release PR exception
- Update item 8.6 to allow tagging merge commits for release branch PRs
- Renumber items 7.5-7.9 to 7.6-7.10
This commit is contained in:
Jim Myhrberg
2026-01-12 08:58:01 +00:00
parent 27fafc85e4
commit e38a08b265
1 changed files with 16 additions and 9 deletions
Download Patch File Download Diff File Expand all files Collapse all files

25
common-flow.md
View File

@@ -168,22 +168,27 @@ interpreted as described in [RFC
"version bump" commit which changes the hard-coded version string of the "version bump" commit which changes the hard-coded version string of the
project. project.
4. When using version bump commits, the release tag MUST be placed on the 4. When using version bump commits, the release tag MUST be placed on the
version bump commit. version bump commit, unless using a release pull request.
5. If you are not using a release branch, then the release tag, and if 5. It is OPTIONAL to use a "release pull request" to propose a release. A
release pull request contains the version bump commit and any
release-related changes (changelog updates, etc.). When using release
pull requests, the release tag SHOULD be placed on the resulting merge
commit.
6. If you are not using a release branch, then the release tag, and if
relevant the version bump commit, MUST be created directly on the main relevant the version bump commit, MUST be created directly on the main
branch. branch.
6. If you are using Conventional Commits, the version bump commit MUST also 7. If you are using Conventional Commits, the version bump commit MUST also
follow the format. For example, "chore(release): 2.11.4". Otherwise, a follow the format. For example, "chore(release): 2.11.4". Otherwise, a
simple "Bump version to 2.11.4" format is acceptable. simple "Bump version to 2.11.4" format is acceptable.
7. Release tags SHOULD be lightweight tags unless you need features that 8. Release tags SHOULD be lightweight tags unless you need features that
annotated tags provide. Annotated tags allow you to include changelog annotated tags provide. Annotated tags allow you to include changelog
information in the tag itself, GPG sign the tag, or include additional information in the tag itself, GPG sign the tag, or include additional
metadata like the tagger's name and email. metadata like the tagger's name and email.
8. If you use annotated release tags, the first line of the annotation 9. If you use annotated release tags, the first line of the annotation
SHOULD read "Release VERSION". For example for version "2.11.4" the first SHOULD read "Release VERSION". For example for version "2.11.4" the first
line of the tag annotation SHOULD read "Release 2.11.4". The second line line of the tag annotation SHOULD read "Release 2.11.4". The second line
MUST be blank, and the changelog SHOULD start on the third line. MUST be blank, and the changelog SHOULD start on the third line.
9. It is OPTIONAL, but RECOMMENDED for high-security projects, to GPG sign 10. It is OPTIONAL, but RECOMMENDED for high-security projects, to GPG sign
release tags. This provides cryptographic verification that the release release tags. This provides cryptographic verification that the release
was created by a trusted party. was created by a trusted party.
8. Short-Term Release Branches 8. Short-Term Release Branches
@@ -198,9 +203,11 @@ interpreted as described in [RFC
5. Short-term release branches MUST have a name of "release-VERSION". For 5. Short-term release branches MUST have a name of "release-VERSION". For
example for version "2.11.4" the release branch name MUST be example for version "2.11.4" the release branch name MUST be
"release-2.11.4". "release-2.11.4".
6. When using a short-term release branch to create a release, the release 6. When using a short-term release branch to create a release, the version
tag and version bump commit if used, MUST be placed directly on the bump commit if used, MUST be created on the short-term release branch.
short-term release branch itself. The release tag MUST be placed on the version bump commit, or on the
merge commit when using a release pull request to merge the release
branch.
7. Only very minor changes should be performed on a short-term release 7. Only very minor changes should be performed on a short-term release
branch directly. Any larger changes SHOULD be done in the main branch, branch directly. Any larger changes SHOULD be done in the main branch,
and SHOULD be pulled into the release branch by rebasing it on top of the and SHOULD be pulled into the release branch by rebasing it on top of the