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.
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).
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.
-
masteralways reflects the staged changes about to go out in the next Maj.min.0release and should always reflect Maj.min.0-SNAPSHOTin its pom.xml. -
Maj.min
.xbranches (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-SNAPSHOTin its pom.xml. -
After cutting a Maj.min.patch release, those changes should also be merged into
master(except for pom.xml changes that violate #1).