QGroundControl Release/Branching process

Semantic Versioning

QGC uses semantic versioning for the version numbers associated with its releases. Semantic versioning is a 3-component number in the format of vX.Y.Z, where:

X is the major version.
Y is the minor version.
Z is the patch version.

Stable Builds

The current stable build is the highest quality build available for QGC. Patch releases of the stable build are regularly made to fix important issues.

Stable builds are built from a separate branch that is named with the format: Stable_VX.Y (note, there is no patch number!) The branch has one or more git tags for each patch release (with the format vX.Y.Z), indicating the point in the repo source code that the associated patch release was created from.

Patch Releases

A patch release contains fixes to the stable release that are important enough to require an update, and are safe enough that the stable release continues to maintain high quality.

Patch releases increment the patch version number only.

Patch - Development Stage

Approved fixes to the stable release are commited to the current stable branch. These fixes continue to queue up in the stable branch until a patch release is made (see next step).

Commits/changes to the stable branch must also be brought over to the master branch (either through cherry pick or separate pulls).

Patch - Release Stage

At the point where the decision is made to do a patch release, the release binaries are created and a new tag is added to the stable branch (with the same patch release number) indicating the associated source code.

New branches are not created for patch releases - only for major and minor releases.

Daily Builds

Development Stage

Daily builds are built from the master branch, and this is where all new major feature development happens. The state of master represents either the next minor point release, or a new major version release (depending on the level of change).

There are no git tags associated with a released daily builds. The released daily build will always match repo HEAD.

Release Stage

When the decision is made to release a new major/minor version the master branch tends to go through an intial lockdown mode. This is where only important fixes for the release are accepted as pull requests.

During the lockdown phase, new features are not allowed in master.

Once the level of fixes associated with the release slows down to a low level, a new stable branch is created (at this point the master branch can move forward again as the latest and greatest).

Fixes continue in the stable branch until it is deemed ready to release (ideally after a short time)! At that point the new stable branch is tagged with the new version tag and the first stable release is made.

Custom Builds

A proposed strategy for branching on custom builds can be found here.

Process to create a new Stable

Major/Minor Version

Create a branch from master named Stable_VX.Y where X is the major version number and Y is the minor version number.
Create a tag on the HEAD of master name dX.Y where the minor version is one greater than the new Stable. For example if you are create a new Stable 4.2 version then the tag would be 'd4.3'. This tag is used to create the version numbers for Android daily builds. Example: git tag -a d4.3.0 -m "QGroundControl Daily Android Version Base".
Create an annotated tag on the newly created Stable branch named vX.Y.0 with the correct major/minor version number. Example: git tag -a v4.2.0 -m "QGroundControl v4.2.0". Pushing this tag to the repo will start a build.
Once the build completes verify the builds are pushed up to S3 correctly and sanity check that they at least boot correctly. Location on S3 will be https://qgroundcontrol.s3.us-west-2.amazonaws.com/latest/....
Update the https://qgroundcontrol.s3.us-west-2.amazonaws.com/builds/latest/QGC.version.txt text file to the latest Stable version. This will notify uses there is a new Stable available the next time they launch QGC.

Patch Version

Creating a new Patch Version is the same except you skip steps 1 and 2 and in step 3 you bump the patch version number up as needed.

QGC Release/Branching Process