Versioning

This document describes conventions for versioning UFS applications.

The goals of the versioning system are that it is:

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

The need for a versioning system for UFS repositories is even greater since these are umbrella repositories that are connected to multiple component repositories that have their own development timelines. So development is expected to occur at a rapid pace. Note, the versioning system outlined here applies to the umbrella applications. The individual components are expected to follow their own versioning guidelines though they are free to use this one if it is suitable.

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