On 1 February 2010 03:24, Steve Borho <st...@borho.org> wrote:
> On Sun, Jan 31, 2010 at 7:51 PM, Adrian Buehlmann <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.
Regards,
Peer
------------------------------------------------------------------------------
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
