Across all of our products, we use a consistent version numbering schema. The idea is to provide a versioning concept which is simple to understand and easy to follow and gives you, the customer, the possibility to track functional differences, improvements and changes in our products. The version number of our products consists of three digits which have a certain meaning regarding the characterization of the specific change. We use a terminology which is common practice in software development.The format is defined as follows:
V[major number].[minor number].[maintenance number], e.g. V1.3.2
In addition, we add an incremental build number that reflects the exact build process run. Depending on the significance of incorporated changes within an update, one of the three digits is incremented. This is briefly described in the following list. In all cases refer to the “changelog” provided with each update in order to get the full detailed picture (also available at our online reference documentation page).
The major number (first digit) indicates a certain architecture and the accompanying interface design. Changes in the major number are only caused by massive changes in the architecture which directly influences the behavior and which can contain massive changes in the interfaces and its signature, i.e. changes in the external APIs of the product. The new release of a product with an incremented major number introduces a new architecture and can contain incompatibilities and breaking changes in the API. The adoption of your application to a new major version, e.g. of the SDK, may require reprogramming on the application side. Generally, the major number of our products will not change very often. Updating to a product version with an incremented major number may in certain cases also require a new license purchase or license upgrade.
The minor number (second digit) indicates functional changes, improvements and enhancements, simply said: feature updates. But in contrast to a new major number, the external API stays compatible when the minor number is increased. Even though the internal APIs of the product may be changed, the external API, e.g. the application side API of the SDK, will remain stable. Updating to new minor version may in very rare cases require some minor changes to your application, but will typically be fully compatible in API and behavior of the component. The previous functionality will remain but may be enhanced. Complete new modules and components may require additional licensing.
The maintenance number (third digit) indicates bug fixing changes only. The release contains cumulated fixes on the bugs that where reported by our various customers and intense power users. An increased maintenance number will contain no new features at all. There will be no API incompatibilities. Updating to a new maintenance release will require minimal effort on the application and just need recompilation or replacement of libraries. There may be several bug fixing updates for a product throughout the year, depending on the severeness of the bugs.