GDS Git Workflow

All work on current and future software projects must use the Git-flow work methodology for tracking work within the repositories.

master Branch

The master branch of every repository is the versions that are currently released to the public. EVERY COMMIT on the master branch must be tagged with a version number of the format x.y.z where x is major version, y is minor version and z is revision version. This is to allow accurate tracking of release builds against the master branch.

develop Branch

The develop branch is where most development should take place, any minor bug fixes and feature implementations should take place in this branch, development builds done from this will have a tag of the last released version followed by the commit number and build hash of the repository. Major feature development should take place on a feature branch with an appropriate name for the feature being implemented. When ready for a preparing a release a releaseCandidate branch will be created from develop. Any bugfixes will be done within the releaseCandidate branch. Any builds from the develop branch will have -develop appended to their full version string.

releaseCandidate Branches

releaseCandidate branches are for preparing versions of software for release, they will usually only contain bugfixes that are found during testing immidiately prior to a release, any builds from releaseCandidate branches will have -releaseCandidate appended to their version string. When a version is ready for release it is to be merged into the master branche, the merge commit to the master branch will be tagged with the new version number and then merged into the develop branch. releaseCandidate branches will be named with the expected version number of the release, eg releaseCandidate/4.0.5, the number will then be what the merge commit to master is tagged with.

hotfix Branches

If it is nessescary to do bugfixes to a released version then a hotfix branch is to be created from the master with the version that was branched in the name, eg hotfix/4.0.3, the bug fix will be implemented within the hotfix branch and then merged into the Master, tagged and merged back into the develop branch.

GDS Version Numbering System

GDS Version numbers consist of a maximum of 6 possible fields.

• Major Version
• Minor Version
• Revision Version
• Commit Number
• Build Hash
• Branch Flag (optional)

An couple of example version numbers could be:

 M.m.r-cn-hhhhhhhh-flags
v1.2.2-32-g6f87d2b-dirty   - from a development build
v2.5.5-64-g70c9dc1-debug   - from a debug build
v2.5.32-64-g70c9dc1        - from a release build of the same version

Major, Minor and Revision Version

The Major, Minor and Revision version numbers are set manually and follow http://semver.org/spec/v2.0.0.html as closely as possible.

A major version consists of a breaking change that is somehow incompatible with a previous version of the software. A minor version is any improvement in functionality that does not constitute a breaking change in compatibility. Revisions are any time a version is released for the purpose of fixing bugs or functionality that already exists in the product.

Minor version resets to 0 when the major version changes. Revision number resets to 0 when the minor version changes.

These numbers are set manually by placing a tag on the commit where the changes get merged into the master branch of the repository. Any internal development should happen in other branches. Once a version is tagged for release it cannot change without incrementing the version.

Commit number

Commit number automatically changes with every patch made to the source code. The number increments automatically and is reset when a new version is tagged.

When building from a releaseCandidate branch the commit number will increment with commits to the branch, it will then reset to 0 when the release version is tagged (when merged to the master branch)

Build Hash

Build Hash is a unique identifier for the version of source code that was used to create the build, this is automatically generated by the version control system and can be used to find the exact version of source code that was used to create the build. This could for instance take the form 63208a0

Branch flags

Branch flags may take a number of forms, the main 3 types are dirty, debug and releaseCandidate.

Debug flags are automatically appended to the end of debugging builds, these may be used for internal testing and under exceptional circumstances sent to customers.

Dirty flags are automatically appended when the build is made from a version of source code that is not stored within VCS, usually because local changes have been made. Any build with a dirty flag is for internal use only and should never leave R&D

releaseCandidate flags are appended when the branch is a release candidate version, this can be for limited release to specific sites but there may be bugs and other issues in the code.

In some instances the master branch flag will appear in a build number, this should only be the case for release versions.

CueSystem PC Application differences

The CueSystem PC application uses the same major, minor and revision values as the embedded applications (although releases are not required to have identical version numbers, for example v4.1.0 of the embedded apps might release alongside v4.1.7 of the PC application). Commit, build and branch information is not available from the PC application due to differences in the build process, however, the date and time the executable was built can be seen on the About window and used to differentiate development versions of the software.