Changelog¶
Version numbering scheme¶
The version numbering scheme is based on semantic versioning. The version number is composed of three parts - major.minor.patch (e.g. 1.0.2) - defining the degree of compatibility between versions.
Major changes¶
Modules with different major version number might not be compatible. This means that modules with different major might not be able to communicate with each other. Furthermore having modules with different major number might lead to exotic behavior as modules assumptions on the data they receive might not hold.
Note
A stack should never run with modules having different major version.
Minor changes¶
Modules with different minor version number are compatible. This implies that no breaking changes are made on the way modules communicate with each other. We might still introduce changes on the communication as long as they are compatible with previous version (i.e. a new field that is ignored by older versions).
A same module with a different minor version number might, on the other hand, introduce changes in its behavior. The behavior of the stack might therefore be modified when updating a module minor version number.
In general upgrading a module to a newer version number will give access to new features without changing the actual behavior of the stack.
Patch changes¶
Changes in the patch version number are bug fixes on previous versions. A module with a new patch number will be totally compatible with the same module with a previous patch version number.
It is always recommended to update modules to the version with the highest patch number.
Security update¶
At present, we exclusively adhere to the latest released version, as version 0.X.Y has been marked as deprecated and should not be used.
Configuration changes¶
New versions of a module might introduce configuration changes. In order to ease version updates the composer might provide automatic configuration update scripts changing an older version of the configuration into a newer one. These scripts are only executed when upgrading a module version from the composer. When downgrading a module, the configuration must be edited manually to be compatible with the previous version (e.g. by reverting the configuration to an older version).