When we started discussing the need to ship a maintenance release for WiX v3.9, we realized that we had no way to easily differentiate a maintenance release from the original “final” release — or any other pre-release build, for that matter.
Traditionally, WiX version numbers have been based on using three fields: major.minor.build. You likely know why: Because Windows Installer uses three version fields and ignores the fourth. Unfortunately, when you want to keep using major.minor versioning, that leaves only one field to identify a particular build.
So we decided to switch things around a bit. We’re now versioning the WiX bundle as major.minor.release.build. The release value is currently zero and will stay that way until/unless we ship a maintenance release. For example, WiX v3.10 RTM might be v220.127.116.110 and a theoretical WiX v3.10 SP1 might be v18.104.22.1683.
The MSI packages in the WiX bundle continue to be versioned as major.minor.build.0, so that major upgrades keep working. The same is true of WiX executables. That means that, for example, Candle.exe from the aforementioned theoretical WiX v3.10 SP1 would have a version of v3.10.2323.0.
I’d rather all the versions — bundle, MSIs, and executables — have the same version number but tagging the bundle with release information is important enough to make this change.
Unfortunately, the new versioning scheme means that new builds of WiX v3.10 are always seen as “less than” any of the already-released WiX v3.10 builds with the old numbering. That means that if you have v3.10.1124.0 installed, for example, v22.214.171.1243 will not be seen as an upgrade. The WiX BA blocks downgrades by hiding the big Install button: