Version numbering

CATS version numbering scheme follows similar approach to what’s known as Semantec versioning (semver). A given version number includes the following parts:

MAJOR.MINOR.PATCH.BUILD

MAJOR: when a version makes incompatible API changes

MINOR: when changes are introduced to the platform in a backwards-compatible manner

PATCH: when making changes to solve production bugs and/or urgent features

BUILD: when making a build

Some parts the version numbering scheme applies to specific environments (long-lived git branches).

Evolving version numbers

It’s important to note that at any give time there will be three versions of CATS which correspond to the three main environments where development/bugfixing takes place. These are development (snapshot), release (vnext) and bugfix (release candidate). Production environment for the most part will have similar codebase to that of release candidate. The convention here is the version on production will always have the smaller version number while the on release candidate will have the higher version number.

Example:

• CATS version 3.0.8 which is on production

• CATS version 3.1.5 -  vNext branch on testing

Relationship between version numbers and environments

As there are three different types of environments in CATS; namely development, testing, and production which correspond to git branches develop, release/bugfix and master respectively; there is a need to identify and track which version is being deployed on which environment.

Versioning follows the following steps/rules:

1. The most recent and unstable version of the platform is found at ‘develop’ branch. There is no version number associated with this codebase since it’s considered as the ‘bleeding edge’ version of the platform.

2. Once enough features are completed to warrant a release, changes from ‘develop’ branch are merged to ‘release’ branch to make the next release codebase. During this time the minor version number is increased by one and this becomes the highest version number in the code base. For example if the previous highest version number was 1.12.0 the new version will become 1.13.0 by increasing ‘minor’ number by one.

3. While on release branch changes in the form of bug fixes will be incorporated into the codebase but will only be affecting ‘build number’ section. It’s only ‘build number’ that is incremented every time a new build is pushed to testing environment. Both ‘minor’ and ‘patch’ numbers remain the same. For example it’s common to see version numbers 1.13.0.130, 1.13.0.131, 1.13.0.122 for the same codebase.

4. Once the code base on release branch is thoroughly tested it’s ready to move to production environment. During this process ‘minor’ number section of the version is bumped by one to reflect there are new features moving to production. For example if the current production version of CATS is 1.12.3.27 then it will be updated to 1.13.0.0 Note that new code base will be moving from develop to release immediately following this and a new version number is created by bumping the ‘minor’ version number by one. In the example above the new version number will become 1.14.0.*.  

5. Finally changes from master should be rebased to bugfix  by merging master to bugfix ensuring the two branches are in sync with eachother.

Relationship between version numbers and git tags

Whenever a new version is created a corresponding tag with the same name should be created within CATS git repository. This will help identify the exact code base associated with a version. On all environments there is an associated build number (the last part of versioning scheme) which is incremented every time a new build is pushed to the corresponding environment. On testing (bugfix branch) environment ‘patch’ number is also incremented when a group of production bugs (sometimes urgent support request) are rolled out to production. Tags within git repo should correspond to version numbers in JIRA.