AudioManager  7.6.6
Native Application Runtime Environment
Versioning

Versioning Mechanism

Versioning should not strictly depend on Version Control System (e.g. git) information. Best approach is to have a dedicated resource exposing the Version of the project. This is achieved via the VERSION file in the main folder of the AudioManager, which content is read by CMake and used in the whole component. Optionally, the flag EXTRAVERSIONINFO can be used to append additional information to the version. VERSION is reporting with the format <Major>.<Minor>.<Revision>. Maintainer of the component should take care of keeping the information aligned with release cycle. Revision should be maintained once patches/fixes are merged to a stabilization branch.

New versioning scheme

Due to the unclearness in the versioning scheme, the versioning scheme changed with release 7.0. Beginning with the 7.0 version, the versioning changed to the semantic versioning described here: http://semver.org/. For every version that released for GENIVI (independent from the compliance), a stable branch will be created which will start with a minor number increase. On the masterbranch, no minor number increases are foreseen.

versioning_new.png

The versioning scheme until 7.0

The versioning scheme was decided in the February face2face 2012.

versioning.png

For the daemon the third number (for example 1.0.X) describes the patch version. The versions are automatically created by git during the build process. The versioning scheme is used for the AudioManager daemon itself and for each of it's interfaces. The versioning of the Interfaces in EA is defined via the tag "version" and the name of the interfaceversion versionName, for example "CommandReceiveVersion". This information is generated into the interface header files and is used then by cmake to set the interface versions. Whenever changes are done, the minor version of the interface needs to be incremented.