Open Test System  
Versioning and Branching

The aim of the versioning and branching concept is to ensure that the versioning of a software version can be clearly identified at any time:

  • Which previous version this software version is based on (i.e. only the changes between these versions are implemented and described in the release notes).
  • Which development branch (main development branch or a stabilization branch) this software version is based on
  • How many change states already exist on a stabilization branch
  • Whether it is a software version released for productive use

In addition, the development process should ensure that:

  • that further development or stabilization that is usable by all users only takes place on a few development branches
  • that new features can be made available early on as part of test versions on the main development branch and that these are immediately recognizable as such

Version Schema

<MainVersion>.<BranchCategoryVersion>.<BranchRevision>.<Revision> (Example: 7.50.48298.49075)

Version Type No. Description
<MainVersion> N The major version number contains new features in defined release cycles. It is continuously incremented.
<BranchCategoryVersion> 0 Delivered major version of the main branch. Exists exactly once per major version.
99 Beta version of the main branch. Will not be incremented.
1+ Stabilization branch for mandatory hotfixes from the last major release. Contains ONLY hotfixes and no new features. Continuously incremented.
50+ Feature branch for mandatory features that are required before the next major release. Can also be used as a stabilization branch. Continuously incremented.
<BranchRevision> Revision number from which a branch was created. Always has the value 0 in the main branch.
<Revision> A unique revision number assigned automatically by the source code management system, which is continuously incremented with each source code change.