Versioning policy

Most versioning systems result in versioning based on numbers. The representation of a version often consists of multiple numbers separated by some separator. Later versions get higher numbers.

The same goes for the Grexx Platform. We use the period (.) as a separator, and versions should be read from left to right and each number denotes an order of less significance the further you go right. So version 1.5.3 was released later than 1.2.7, but earlier than 1.5.15.

Whenever a number left of some separator is increased, the numbers to the right of that separator are reset to 0.

When choosing versioning policies, we made an explicit choice between semantic versioning (where major versions imply breaking changes) or a more chronological versioning (year, sprint, hotfix). As we are dealing with several different components (API, GUI, database, etc.) the semantic versioning system inherently leads to different versions (ie API v3.2 matches with GUI v15.4.2). We've chosen for the chronological versioning to be able to quickly recognize API and GUI versions that match and should be compatible. We thereby also directly define that hotfixes get the third part of the versioning number and should be compatible with its counterpart components. Ie API 6.4.2 is the second hotfix on version 6.4 and should be compatible with GUI versions 6.4 and 6.4.x.

This choice gives more clarity in communication and ability to match versions, but does imply that the version numbers don't tell you anything about the majority of difference between versions.

We started version 1 in 2014, version 2 in 2015 etc. The second number represents the development iteration (sprint). That means that for example version 5.17 is the result of the 17th development iteration of 2018. 5.17.5 is the 5th hotfix version of the same release.