Release Code Management

We make every effort to ensure our releases strictly adhere to the Semantic Versioning Specification without exception.

To help facilitate this, our git branching philosophy is as follows.

Master

The master branch always reflects the next minor release baseline. It contains all merged PRs and changes awaiting the next Maj.min.0 release.

For example, the maven pom.xml version will always look like 0.10.0-SNAPSHOT, 0.11.0-SNAPSHOT, 1.0.0-SNAPSHOT, etc).

Patches

If a bugfix or patch release is warranted for any Maj.min.0 release, a branch is created from the Maj.min.0 release tag with a Maj.min.x naming scheme (suffix is the actual string literal .x)

For example, if 0.9.0 has been released, and we need to get a patch out, we create a 0.9.x branch from the 0.9.0 release tag, and that branch reflects 0.9.1-SNAPSHOT and contains merged PRs awaiting the patch release.

When 0.9.1 is about to be released, the pending changes also get merged to master (to ensure they're always in all future Maj.min releases). Then 0.9.1 is released and then the 0.9.x branch reflects 0.9.2-SNAPSHOT in its pom.xml files.

At this point we can either keep the 0.9.x branch around if we think there might be further patch releases (0.9.2, 0.9.3, etc), or just delete it. If we delete it and a 0.9.2 release is warranted, we would re-create the 0.9.x branch from the 0.9.1 tag.

We tend to prefer to delete .x branches after a patch release to keep things clean unless we know there is an immediate need for another follow-up patch very soon.

Summary

1. master always reflects the staged changes about to go out in the next Maj.min.0 release and should always reflect Maj.min.0-SNAPSHOT in its pom.xml.

2. Maj.min.x branches (suffixed with the string literal '.x') always reflect staged changes about to go out in the next Maj.min.patch release and should always reflect Maj.min.patch-SNAPSHOT in its pom.xml.

3. After cutting a Maj.min.patch release, those changes should also be merged into master (except for pom.xml changes that violate #1).