As anyone who has used the platform extensively knows; we custom-build your MSI installers using your own custom settings, scripts, and branding. This has led to some interesting challenges with version numbers and Windows Installer.
When we started, we used version numbers in the following format: major.minor.patch.build. This is the standard way version numbers work and even has an official standard called “Semantic Versioning”. It is with great distress that we had to break from that standard. The problem lies in the fact that windows installer service acts funky with that last number. If you have version 22.214.171.124 of software-X installed and then try to install version 126.96.36.199, then windows installer will perform an upgrade and you will now have version 188.8.131.52 and not 184.108.40.206 installed as would be expected. BUT! If you have version 220.127.116.11 of software-X installed and then try to install version 18.104.22.168, then windows installer will install the new software alongside the other version and you will now have two versions of the software installed; 22.214.171.124 and 126.96.36.199.
Our software can’t be distributed like normal software; we can’t just put up the official versions on a download page somewhere. Each build is unique to you. It has your custom logos settings and scripts, so there is no “official version”. Our plan from the beginning was to use the first 3 numbers of the version to ourselves and increment the last one for each of your custom builds. So, for example, we would release version 1.2.3 and when you build against that version, you would get 188.8.131.52 and next time your build against that version you would get 184.108.40.206, then 220.127.116.11, etc.… It’s the logical way to handle things.
But since we can’t do that, we are instead taking that last number and swapping it for the second-last. Now we release versions like 1.2.x.3 and your builds end up like 18.104.22.168, and then 22.214.171.124, and then 126.96.36.199. It’s a weird way to implement version numbers, but it was the only option to prevent windows installer from misinterpreting our intentions and still give you the flexibility to build same-version upgradable packages that can be deployed without first having to uninstall the previous version.