Versioning of modules and applications¶
Versioning approach¶
The versioning scheme of the PSS®X modules and applications follows the rules of Semantic Versioning 2.0.0.
The PSS®X repositories are versioned independently from each other. Therefore, a version number is only meaningful in the repository to which it belongs; it will typically have a completely different meaning in any other repository.
This approach applies to releases as well as release candidates and development versions.
Versioning in repositories¶
Git tags are used to represent version numbers:
- Release versions (e.g. "1.1.0") are used on the
release
branch only. - Release candidate versions (e.g. "1.1.1-rc.1") are used on the
release/rc1.1.1
branch only. - Development versions (e.g. "1.1.2-alpha.0") will be used on
development
branch only. - Feature development (e.g. "1.1.2-abc.0") will be used on
feature/abc
branch only.
References between repositories¶
Any reference to other PSS®X modules uses a fixed version number on the main
, release
or branch (release versions) and on the release/rc
branch (release candidate). To simplify continuous integration, relaxed versions (e.g. "latest") may be used for development
if needed.
When a repository contains a reference to another repository, the referenced version of the repository should always have the same or higher degree of maturity than the referencing repository.
This means that:
- Release versions do only reference other release versions.
- Release candidates do only reference other release candidates or release versions
- Development versions do reference development versions, release candidates or release versions. Relaxed version references are possible.
Semantic Versioning 2.0.0 in a nutshell¶
Semantic Versioning is a versioning scheme well-accepted and widely used throughout the software engineering community. It is supported or even required by many tools. A really good and easily understandable specification of Semantic Versioning (SemVer) is available on the Semantic Versioning home page.
A version number MAJOR.MINOR.PATCH is comprised of three non-negative integers separated by dots (e.g. "1.1.0"). The version numbers are increased as follows:
- MAJOR: Incompatible API changes have been made.
- MINOR: Functionality has been added in a backwards compatible manner.
- PATCH: Backwards compatible bug fixes have been.
Optionally, a version number may contain:
- Pre-release version separated by a hyphen (e.g. "1.12.5-alpha.120", "1.2.8-rc.1).
- Build metadata separated by a plus sign (e.g. "1.12.5-alpha.120+CIID").
Semantic Versioning defines rules for ordering artifacts based on their version number.