Versions Compared

Old Version 3

changes.mady.by.user Nick Couchman

Saved on

compared with

New Version Current

changes.mady.by.user Mike Jumper

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

We use a set of three branches to maintain the code/documentation for current and upcoming releases:

Branch NameDescription
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 patch  branch, the patch  branch is merged back to main , and the main  branch is merged to next . In extreme cases, changes to patch  may need to be reimplemented against next .

The patch branch always represents the next possible patch release that is not yet being staged. Prior to the creation of a staging/X.Y.Z  branch, this is relative to the most recent release. After the creation of a staging/X.Y.Z  branch, this is relative to the staged release (ie: it represents the basis of a possible future "X.Y.[Z+1]"  release).

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 main branch, the patch  branch is merged back to main , and the main  branch is merged to next . In extreme cases, changes to patch  may need to be reimplemented against next .

The main branch always represents the next possible minor release that is not yet being staged. Prior to the creation of a staging/X.Y.Z  branch, this is relative to the most recent release. After the creation of a staging/X.Y.Z  branch, this is relative to the staged release (ie: it represents the basis of a possible future "X.[Y+1].Z"  release).

next

Receives any changes that are too large in size or effect to be considered for main .

The next branch always represents the next possible major release that is not yet being staged. Prior to the creation of a staging/X.Y.Z  branch, this is relative to the most recent release. After the creation of a staging/X.Y.Z  branch, this is relative to the staged release (ie: it represents the basis of a possible future "[X+1].Y.Z"  release).

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

...

When a change for an upcoming release is merged to that release's staging branch, the staging branch needs to be merged back to the base branch that originated that release (ie: If it's a patch release, merge back to patch. If it's a minor release, merge back to main, etc.). The suggested commit messages for these merges are: patch  (as the patch  branch now represents a possible future patch release relative to the release being staged). This includes when the release staging branch is first created for anything but a patch release. The suggested commit message for this merge is:

  • If X.Y.Z is a patch release: "Merge X.Y.Z changes back to patch."
  • If X.Y.Z is a minor release: "Merge X.Y.Z changes back to minor."
  • If X.Y.Z is a major release: "Merge X.Y.Z changes back to next."

Once those changes have been merged back, follow the same procedures shown below as would be followed if those changes were merged by a direct PR against that branch.

...

  • "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.

...