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

Restructure release branch sections

Browse Source
This commit is contained in:
Jim Myhrberg
2017-07-06 00:46:19 +01:00
parent ba6fac3692
commit 4b1dac4d2d
1 changed files with 34 additions and 34 deletions
Download Patch File Download Diff File Expand all files Collapse all files

68
common-flow.md
View File

@@ -115,39 +115,39 @@ interpreted as described in [RFC 2119](https://tools.ietf.org/html/rfc2119).
into the master branch, that work should have happened against the master into the master branch, that work should have happened against the master
branch in the first place. One exception to this is version bump commits. branch in the first place. One exception to this is version bump commits.
4. There are two types of release branches; short-term, and long-term. 4. There are two types of release branches; short-term, and long-term.
6. Short-Term Release Branches 5. Short-Term Release Branches
1. Used for creating a specific versioned release. 1. Used for creating a specific versioned release.
2. A short-term release branch is RECOMMENDED if there is a lengthy 2. A short-term release branch is RECOMMENDED if there is a lengthy
pre-release verification process to avoid a code freeze on the master pre-release verification process to avoid a code freeze on the master
branch. branch.
3. MUST have a name of "release-VERSION". For example for version 3. MUST have a name of "release-VERSION". For example for version
"2.11.4" the release branch name MUST be "release-2.11.4". "2.11.4" the release branch name MUST be "release-2.11.4".
4. When using a short-term release branch, the version bump commit and 4. When using a short-term release branch, the version bump commit and
release tag MUST be made directly on the release branch itself. release tag MUST be made directly on the release branch itself.
5. Only very minor changes should be performed on a short-term release 5. Only very minor changes should be performed on a short-term release
branch directly. Any larger changes SHOULD be done in the master branch, branch directly. Any larger changes SHOULD be done in the master
and SHOULD be pulled into the release branch by rebasing it on top of the branch, and SHOULD be pulled into the release branch by rebasing it
master branch the same was a change branch pulls in updates from its on top of the master branch the same was a change branch pulls in
source branch. updates from its source branch.
6. After the version bump commit and release tag have been created, the 6. After the version bump commit and release tag have been created, the
release branch MUST be merged back into its source branch and then release branch MUST be merged back into its source branch and then
deleted. Typically the source branch will be the master branch. deleted. Typically the source branch will be the master branch.
7. Long-Term Release Branches 6. Long-Term Release Branches
1. Used for work on versions which are not currently part of the master 1. Used for work on versions which are not currently part of the master
branch. Typically this is useful when you need to create a new branch. Typically this is useful when you need to create a new
maintenance release for a older version. maintenance release for a older version.
2. The branch name MUST have a non-specific version number. For example 2. The branch name MUST have a non-specific version number. For example
a long-term release branch for creating new 2.9.x releases would be a long-term release branch for creating new 2.9.x releases would be
named "release-2.9". named "release-2.9".
3. To create a new release from a long-term release branch, you MUST 3. To create a new release from a long-term release branch, you MUST
create a version bump commit and release tag directly on the release create a version bump commit and release tag directly on the release
branch. branch.
4. A long-term release branch MUST be created from the relevant release 4. A long-term release branch MUST be created from the relevant release
tag. For example if there is a security fix for all 2.9.x releases, tag. For example if there is a security fix for all 2.9.x releases,
the latest of which is "2.9.7", we create a new branch called the latest of which is "2.9.7", we create a new branch called
"release-2.9" off of the "2.9.7" release tag. The security fix "release-2.9" off of the "2.9.7" release tag. The security fix
release will then end up being version "2.9.8". release will then end up being version "2.9.8".
8. Bug Fixes & Rollback 6. Bug Fixes & Rollback
1. You MUST NOT under any circumstances force push to the master branch. 1. You MUST NOT under any circumstances force push to the master branch.
2. If a change branch which has been merged into the master branch is found 2. If a change branch which has been merged into the master branch is found
to have a bug in it, the bug fix work MUST be done as a new separate to have a bug in it, the bug fix work MUST be done as a new separate
@@ -157,7 +157,7 @@ interpreted as described in [RFC 2119](https://tools.ietf.org/html/rfc2119).
reason the merge must be undone, you MUST undo the merge by reverting the reason the merge must be undone, you MUST undo the merge by reverting the
merge commit itself. Effectively creating a new commit that reverses all merge commit itself. Effectively creating a new commit that reverses all
the relevant changes. the relevant changes.
9. Git Best Practices 7. Git Best Practices
1. All commit messages SHOULD follow the Commit Guidelines and format from 1. All commit messages SHOULD follow the Commit Guidelines and format from
the official git the official git
documentation: documentation: