...
We use a set of three branches to maintain the code/documentation for current and upcoming releases:
Branch Name | Description |
---|---|
patch | Receives only bug fixes and minor improvements. Changes to this branch can be released more quickly via patch releases, but must not require any substantial changes to documentation or established application behavior. After changes have been merged to the The |
main | Receives essentially any changes except huge changes that would reasonably require a full version bump (ie: moving from 1.x all the way to 2.x). Examples of changes that should not go here include compatibility-breaking migrations away from established frameworks and rewrites of the user interface. After changes have been merged to the The |
next | Receives any changes that are too large in size or effect to be considered for The |
When the scope of a release is frozen to allow the code/documentation to be finalized prior to release, an additional staging branch will be created for that release:
Branch Name | Description |
---|---|
staging/X.Y.Z | Receives only changes related to release "X.Y.Z". At the time this branch is created, all issues related to that release are already associated with that release in JIRA using the "Fix version/s" field. |
Merging Changes
Depending on the branch receiving a change, that branch may need to be additionally merged to other branches to ensure a consistent line of development.
...
- "Merge changes from patch branch back to main."
- "Merge changes from main branch back to next."
Changes to main
When a change is merged to main
, the main
branch must be merged to next
. The suggested commit message for this merge is:
- "Merge changes from main branch back to next."
Changes to next
Do nothing. Changes to next
do not get merged to other branches.
...