QGC uses semantic versioning for the version numbers associated with its releases. Semantic versioning is a 3-component number in the format of
Xis the major version.
Yis the minor version.
Zis the patch version.
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.
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.
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).
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 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.
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.
A proposed strategy for branching on custom builds can be found here.
- Create a branch from master named
Xis the major version number and
Yis the minor version number.
- Create a tag on the HEAD of master name
dX.Ywhere 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.0with 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
- Update the
https://qgroundcontrol.s3.us-west-2.amazonaws.com/builds/latest/QGC.version.txttext file to the latest Stable version. This will notify uses there is a new Stable available the next time they launch QGC.
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.