Over the years, we saw many approaches on how to work with software versioning. There are famous and infamous examples on how to do this. With the shift to the cloud, new versions are automatically applied and maybe less apparent, but they still happen and can introduce breaking changes.

For us, as developers of an application framework, we want to be very clear with our release strategy and give you clear indications on how to deal with version changes. Having a common ground about the release strategy will help you reduce friction, in case we’re having breaking changes.

So, let’s see how we approach these topics:

Version Pattern

We use the classic pattern you often see with other software: x.y.z

• x = MAJOR version: Incompatible changes

• y = MINOR version: Functionality added in a backwards compatible manner

• z = PATCH version: Backwards compatible bug fixes

If we introduce a new feature that is not backwards compatible, or think about a new configuration scheme, we will raise the major version. In that way, you, as an Administrator know, that a major upgrade needs manual migration steps.

If we add functionality – to the latest major version – that is backwards compatible, we will release a minor version. For you as, an Administrator, this means an update without manual migration steps. Maybe you need to configure the new feature, but existing functionality dos not break.

Patches address bugs. No features added, no breaking changes. You can use patch-versions with no manual migration steps.

Our approach to versioning is based on https://semver.org/spec/v2.0.0.html⁣ – we consider this an industry standard, we shouldn’t reinvent.

Release Cycle

A consequence of our approach to versioning, is, that we cannot predict a date for releases. Instead of dropping yearly a major release, we will release as it is needed.

Naming

When we prepared for the release of 6.x, we felt, that the product “earned” a proper name. Being a team rooted in Austria, we went for a local naming schema. Every Major-Version now gets a name to make releases distinguishable beyond numbers.

The naming convention will soon be very obvious to you

Documentation

With the switch over from 6.x to 7.x we will also start to version our online documentation. This will help you to better understand which feature/setting is available in what version.