Why bugfix release updates make more sense than hotfixes

In general, we do not recommend doing hotfixes. However, sometimes there are exceptional cases where a hotfix is unavoidable. But this can only be a short-term solution when no workaround is possible to solve a critical incident. Due to the below reasons, this shouldn't be the general process.

Hotfixes are not comparable to a release update

A bugfix release includes several bug fixes which are fixing security vulnerabilities or other bugs and improving the usability or performance.

We are trying hard to make bugfix release updates as easy and safe as possible. In order to avoid the risk of breaking the functionality a bugfix release does normally not include database changes, there is no new functionality or new features added to enhance the product functionality, every change is documented and all releases have gone through a test cycle.

With systems that are accessible from the internet, the fast installation of security updates becomes more and more important and should not be ignored.

Indeed, there's a small but unavoidable chance that these fixes might introduce new issues. But that's software. All software vendors try hard to prevent this, but it still happens.

By applying several hotfixes, you won't get an installation that is QA -tested and comparable to other installations. This can only be achieved by updating to a bugfix release version.

Because manually applying hotfixes is more time-consuming and error-prone, it requires more effort in terms of costs and is risky as well, it is better to directly update to the latest bugfix release. The risk of unknown side effects (e.g. breaking the functionality) which can be caused by the accumulation of hotfixes can be avoided then. Last but not least the testing effort should be the same for hotfixes and bugfix release updates.

It makes sense to establish a process where you define how frequently you would like to update to the latest bugfix release (e.g. every 4 to 8 weeks cycle).

Update is not upgrade

The numbering schema is: major version - minor version - patch version. So any fix results and has to result in a new patch version number.

When it comes to a technical recommendation to apply bugfixes from the currently (e.g. 5.6.5) installed version to the latest bugfix release version (e.g. 5.6.6), it's called update.

When it comes to a technical recommendation to expand the current product functionality of the currently installed version (e.g. 5.6.5) to get access to new features of a minor (e.g. 5.7.0) or major version (6.0.0), it's called an upgrade.