Versioning

The goals of the versioning system are that it is:

• Simple to implement and understand
• Well documented
• Consistently applied

The proposed UFS versioning system is: vXX.YY.ZZ

XX -- Release upgrade Is updated every time there is a release of the UFS application Requires extensive benchmark testing that documents the skill of the application Following the gitflow approach, a release candidate branch should be created from the develop branch where the application is extensively tested before moving to the master branch with the release tag Release applications should ensure, as much as possible, that they are connected to component releases Release applications should ensure as complete documentation as possible

YY -- Feature upgrade These are incremented for upgrades in between releases Should be updated every time One of the components are updated A new component is added Need not be updated for bug fixes (see bug fix upgrade) Regression tests need to be completed before incrementing versions

ZZ -- Bugfix upgrade These are incremented when a bug fix needs to be applied to a release Since feature upgrades are periods of rapid developments where multiple bugs are expected to be found, it is not necessary to increment this during the feature development phase (in between releases) All bug fixes that are applied to the master branch (release application) should be applied to the develop branch (develop application) if they have not yet been incorporated in the application yet. However, not all bug fixes that are applied to the develop application need be applied to the release application.
All version changes should be documented in the wiki associated with the application in GitHub. Version numbers should be accounted for in two ways -- A flat file in the repository, and a tag. The flat file allows for clear identification of the version number away from the repository. Tags allow for users to easily check out a particular version. To avoid an explosion of tags, applications can use the following guidelines for tags All releases should be associated with version tags Only major milestones in development need version tags. In between can just be updates that are documented by updating the version number and documenting in the wiki