I would agree with Michael on this one. Try to put less meaning into the MSI version number. Or use that version number as the marketing number for the product.
This would mean that you would have major.minor.build (1.0.0) but that would more reflect major.minor (1.0) on the MSI side of things. So, internally you have something like below that is your FIRST release to the world: 1.0.0 Next you need to patch that release...we'll say at least twice. This however does not warrant changing the product version at the marketing level as you haven't charged the customer more money for the update. So the ProductVersion number stays the same. 1.0.0 Now you have a minor upgrade. This is something that you can charge the client base for so they want to make sure that they have the correct MSI installed. Then you would have the number listed below. 1.1.0 If the product is a .NET application that is going to be GAC'd it is common to use the above versions for the AssemblyVersionAttribute<http://msdn.microsoft.com/en-us/library/system.reflection.assemblyversionattribute(VS.85).aspx>. The you would update the version to the actual number on the AssemblyFileVersionAttribute<http://msdn.microsoft.com/en-us/library/system.reflection.assemblyfileversionattribute(VS.85).aspx>. I believe, if you really need to have letters, you might be able to use the AssemblyInformationalVersionAttribute<http://msdn.microsoft.com/en-us/library/system.reflection.assemblyinformationalversionattribute(VS.85).aspx>in order to display the value. Althought I don't actually know what the Windows Installer team was thinking when they forced the versioning to be done in this manner, I believe this is along the lines of what they were thinking. There is a link to this URL in the Wix.chm under patching (and listed below) this might help you decide on how you want to move forward with your MSI ProductVersion property. Patching and Upgrades<http://msdn.microsoft.com/en-us/library/aa370579(VS.85).aspx> I hope that helps, Brian Rogers "Intelligence removes complexity." - Me http://icumove.spaces.live.com On Tue, Jan 6, 2009 at 5:39 PM, Michael Osmond <mosm...@baytech.com.au>wrote: > Hi, > > The approach I would recommend is try not to put so much meaning into > the version number. Make the MSI version number something simple, which > always changes. > > We have deliberately restricted things to Major.Minor.build for the MSI > version number. Internally the buil number is rolled every time > anything changes, so nothing would be released that would not be > different (well almost but that's a different story). > > If you want or need the other information put it somewhere else - in a > reg key, in the product name in Add/Remove programs, in the Summary > Information. > > Michael > > > -----Original Message----- > From: lesterbangs [mailto:datapa...@gmail.com] > Sent: Wednesday, 7 January 2009 11:26 AM > To: wix-users@lists.sourceforge.net > Subject: Re: [WiX-users] Letters in ProductVersion > > > > Polite bump on this... > Am I approaching this from the wrong angle? I mean, I know I can easily > add a registry entry with the version string in any format I want, but I > am more concerned about how to identify the product in x.y.z format in > order for upgrades to work. > There must be someone else here that has to deal with weird product > versions... > > lesterbangs wrote: > > > > Our product versions mostly conform to the major.minor.build > > convention specified by the MSI standard, but sometimes we have to put > > > letters in the strings to indicate an update or "hotfix", i.e. > 1.0.5.U1 or 2.4.16.HF02. > > > > Obviously this is a big no-no to have letters in ProductVersion > property. > > Worse, sometimes we have updates to hotfixes, or vice-versa, such as > > 3.1.72.U1.HF04. > > > > I imagine we would have to come up with some sort of "translation > table" > > to convert a numbers-letters string to a pure numbers string that MSI > > can understand. I.e. 2.4.16.HF02 becomes 2.4.1602 and 1.0.5.U1 becomes > > > 1.0.5100. > > > > According to the specification, Windows Installer ignores anything > > after the 3rd field. So even if we were able to change it to all > > numbers, > > 3.1.72.U1.HF04 would become 3.1.72.01.04, but only 3.1.72 would be > > recognized. 3.1.720104 would also not work, as field 3 cant be larger > > than 65536. 3.1.7214 would work but only for update numbers less than > 10. > > > > This could get confusing very fast. Is anyone in a similar situation? > > What is the easiest way to mitigate this issue? > > > > -- > View this message in context: > http://n2.nabble.com/Letters-in-ProductVersion-tp2113603p2120366.html > Sent from the wix-users mailing list archive at Nabble.com. > > > ------------------------------------------------------------------------ > ------ > Check out the new SourceForge.net Marketplace. > It is the best place to buy or sell services for > just about anything Open Source. > http://p.sf.net/sfu/Xq1LFB > _______________________________________________ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > > > ------------------------------------------------------------------------------ > Check out the new SourceForge.net Marketplace. > It is the best place to buy or sell services for > just about anything Open Source. > http://p.sf.net/sfu/Xq1LFB > _______________________________________________ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > ------------------------------------------------------------------------------ Check out the new SourceForge.net Marketplace. It is the best place to buy or sell services for just about anything Open Source. http://p.sf.net/sfu/Xq1LFB _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
