This ProductVersion restriction really is an odd construct. Maybe it has to do with the parsing of the Upgrade table? The third version digit is an unsigned integer or short, whereas the two first digits are unsigned bytes. From the SDK:
The first field is the major version and has a maximum value of 255. The second field is the minor version and has a maximum value of 255. The third field is called the build version or the update version and has a maximum value of 65,535.
Whatever the restriction is based on, it isn't great for today's daily build style development where people often seem to standardize on using the fourth digit for "qa only internal builds" whilst still delivering them internally via major upgrades, and then perhaps bumping up the third digit when a full QA is due for the whole product, and not just for new features and changes - an alfa, beta or gold release candidate setup.
This kind of release and team conventions are very important for collaboration and awareness in large and small teams alike. Anyone in release and configuration management will experience this, especially when you add to it delivering multiple versions of the product in different languages - then you realize that the version number standardization can be much more important than you first think. You generally also need a setup name that specifies language (and cpu type, and other things): Prod_18.104.22.16845-eng-x64.exe and then sign the setup with certificates when it is ready for public release.
If I were to chose how the ProductVersion would work I would go for:
255.255.255.65535 - or byte,byte,byte,uint (255.255.65535.65535 - seems excessive)
But this will never happen since it isn't backwards compatible with older setups. Explaining these version number restrictions to a team of developers is a challenge in and of itself.
In any event the "problem" with the three digit version number comes up as a question often enough to be a genuine usability issue with Windows Installer.
Edited by Glytzhkof, 09 April 2014 - 13:52.