On 01.02.2010 13:29, Peer Sommerlund wrote: > > > On 1 February 2010 03:24, Steve Borho <st...@borho.org > <mailto:st...@borho.org>> wrote: > > On Sun, Jan 31, 2010 at 7:51 PM, Adrian Buehlmann > <adr...@cadifra.com <mailto:adr...@cadifra.com>> wrote: > > Since we will be going to switch to doing *.msi installers, > > I'll post what I have learned while doing non-TortoiseHg > > Windows installers (this is in no way restricted to using WiX): > > > > Windows installer packages must have product versions in the form > > > > 999999.999999.999999.999999 > > (A) (B) (C) (D) > > > > That is: 4 groups of digits. No other characters are allowed. > > > > It is possible to specify string version resources, but these are > ignored > > by Windows Installer (visible in the properties dialog of an exe > or dll). > > > > Windows Installer only respects "binary" file versions (as noted > above). > > > > Windows installer ignores the fourth group (D). > > > > This means, at least one of A, B or C must be counted up when > publishing > > a new, regular msi installer for a product, intended to replace all > > "previous" installer versions ever published. > > > > Otherwise, users will get an error message of the form "The same > > version of this product is already installed" and installation is > refused, > > meaning they have to manually uninstall before installing the 'update' > > (Windows Installer will notice that the two installers are > different by > > looking at a GUID in the msi, but it will not be able to tell > which one > > is "newer"). > > > > Windows applications usually count up D when doing a new build. > > > > So if a Windows application pushes out a broken 0.9.2.? release, > they have > > to name the fix 0.9.3.0 (or higher). > > > > Doing a 0.9.2.1 to fix 0.9.2.0 does not work, because Windows > Installer > > ignores the fourth group when considering updates. > > It's been suggested to me by Matt and others that we should declare a > 1.0 release soon. This seems like as good of an excuse as any to > declare 1.0.0 for the initial MSI installer. > > This still leaves us problems for nightly builds, it seems. Assuming > we keep to our monthly release schedule, I suppose we could number > stable nightlies from 1.0.50..99 and unstable nightlies from > 1.0.100..200. This leaves room for up to 50 "patch" releases, 50 > stable nightly builds, and as many unstable nightlies as we need. > > Feels kludgy, but I don't have any better ideas at the moment. > > > How many digits are available in each number? > > How about > > 1.3 = 0103.0.0 > 0.9.2 = 0009.0200.0 > 0.9.2.1 = 0009.0201.0 > 0.9 stable nightlies, after release 0.9.2.1 = 0009.0201.i, where i > increments by every nightly > 0.9 unstable nightlies (pre 0.10) = 0009.10000.i, where i either is rev# > of tip, or simply increment by one every nightly build.
A, B, C and D are just non-negative ordinal numbers, not strings. So no leading zeros. ------------------------------------------------------------------------------ The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com _______________________________________________ Tortoisehg-develop mailing list Tortoisehg-develop@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tortoisehg-develop
