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

Update release branch sections

Browse Source 
- Fixes #9
- Restructures "Release Branches" section with it's sub-sections into
  two separate top-level sections for short-term and long-term release
  branches.
This commit is contained in:
Jim Myhrberg
2017-08-08 20:50:55 +01:00
parent 7858131cf5
commit 62f817a5ea
1 changed files with 51 additions and 44 deletions
Download Patch File Download Diff File Expand all files Collapse all files

91
common-flow.md
View File

@@ -131,51 +131,58 @@ interpreted as described in [RFC 2119](https://tools.ietf.org/html/rfc2119).
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 MUST start on the third line. MUST be blank, and the changelog MUST start on the third line.
7. Release Branches 7. Short-Term Release Branches
1. Any branch that has a name starting with "release-" SHOULD be referred to 1. Any branch that has a name starting with "release-" SHOULD be referred to
as a "release branch". as a "release branch".
2. Use of release branches is OPTIONAL. 2. Any release branch which has a name ending with a specific version
3. Changes in a release branch SHOULD typically come from work being string, MUST be referred to as a "short-term release branch".
done against the master branch. Meaning changes SHOULD only trickle 3. Use of short-term release branches are OPTIONAL, and intended to be used
downwards from the master branch. If a change needs to trickle back up to create a specific versioned release.
into the master branch, that work should have happened against the master 4. A short-term release branch is RECOMMENDED if there is a lengthy
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.
5. Short-Term Release Branches
1. Used for creating a specific versioned release.
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 5. Short-term release branches MUST have a name of "release-VERSION". For
"2.11.4" the release branch name MUST be "release-2.11.4". example for version "2.11.4" the release branch name MUST be
4. When using a short-term release branch, the version bump commit and "release-2.11.4".
release tag MUST be made directly on the release branch itself. 6. When using a short-term release branch to create a release, the release
5. Only very minor changes should be performed on a short-term release tag and if used, version bump commit, MUST be placed directly on the
branch directly. Any larger changes SHOULD be done in the master short-term release branch itself.
branch, and SHOULD be pulled into the release branch by rebasing it 7. Only very minor changes should be performed on a short-term release
on top of the master branch the same way a change branch pulls in branch directly. Any larger changes SHOULD be done in the master branch,
updates from its source branch. and SHOULD be pulled into the release branch by rebasing it on top of the
6. After the version bump commit and release tag have been created, the master branch the same way a change branch pulls in updates from its
release branch MUST be merged back into its source branch and then source branch.
deleted. Typically the source branch will be the master branch. 8. After a release tag has been created, the release branch MUST be merged
6. Long-Term Release Branches back into its source branch and then deleted. Typically the source branch
1. Used for work on versions which are not currently part of the master will be the master branch.
branch. Typically this is useful when you need to create a new 8. Long-term Release Branches
maintenance release for a older version. 1. Any release branch which has a name ending with a non-specific version
2. The branch name MUST have a non-specific version number. For example string, MUST be referred to as a "long-term release branch". For example
a long-term release branch for creating new 2.9.x releases would be "release-2.11" is a long-term release branch, while "release-2.11.4" is a
named "release-2.9". short-term release branch.
3. To create a new release from a long-term release branch, you MUST 2. Use of long-term release branches are OPTIONAL, and intended for work on
create a version bump commit and release tag directly on the release versions which are not currently part of the master branch. Typically
branch. this is useful when you need to create a new maintenance release for a
4. A long-term release branch MUST be created from the relevant release older version.
tag. For example if the master branch is on version 2.11.4 and there 3. A long-term release branch MUST have a name with a non-specific version
is a security fix for all 2.9.x releases, the latest of which is number. For example a long-term release branch for creating new 2.9.x
"2.9.7". Create a new branch called "release-2.9" off of the "2.9.7" releases MUST be named "release-2.9".
release tag. The security fix release will then end up being version 4. Long-term release branches for maintenance releases of older versions
"2.9.8". MUST be created from the relevant release tag. For example if the master
8. Bug Fixes & Rollback branch is on version 2.11.4 and there is a security fix for all 2.9.x
1. You MUST NOT under any circumstances force push to the master branch. releases, the latest of which is "2.9.7". Create a new branch called
"release-2.9" off of the "2.9.7" release tag. The security fix release
will then end up being version "2.9.8".
5. To create a new release from a long-term release branch, you MUST follow
the same process as a release from the master branch, except the
long-term release branch takes the place of the master branch.
7. A long-term release branch should be treated with the same respect as the
master branch. It is effectively the master branch for the release series
in question. Meaning it MUST always be in a non-broken state, MUST NOT be
force pushed to, etc.
9. Bug Fixes & Rollback
1. You MUST NOT under any circumstances force push to the master branch or
to long-term release branches.
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
change branch and MUST follow the same workflow as any other change change branch and MUST follow the same workflow as any other change
@@ -184,7 +191,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 10. 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: