On 20.02.2010 19:21, Steve Borho wrote: > On Sat, Feb 20, 2010 at 9:14 AM, Adrian Buehlmann <adr...@cadifra.com> wrote: >> I've pushed a change to thg-winbuild that changes the names of the msi >> output files (8462b6eb15d4 [1]). >> >> Example of a previous package name: >> tortoisehg-stable-0.9.3+156-84af109559ef-hg-1.4.3+184-98bc3e195720-x86.msi >> >> Example of a new package name: >> tortoisehg-stable-0.9.31158-x86.msi >> >> This conforms with the version recorded in the installed programs >> control panel of Windows (e.g. 0.9.31158). >> >> This should make it easier for users to locate the msi that was used for >> installing in case they want to repair an existing install. >> >> The exact thg and hg versions installed by an msi can still be found out >> by opening the properties dialog of the msi: on the "Details" tab there >> is a property "Comments" (see also thg-winbuild change d12fe39d9416 [2]). >> >> For example, the Comments property of tortoisehg-stable-0.9.31158-x86.msi >> has the text "Installs TortoiseHg 0.9.3+158-910975e21005, >> Mercurial 1.4.3+186-13448eab08ca". >> >> So it is still possible to find out the exact thg and hg versions before >> installing anything. >> >> [1] http://bitbucket.org/tortoisehg/thg-winbuild/changeset/8462b6eb15d4 >> [2] http://bitbucket.org/tortoisehg/thg-winbuild/changeset/d12fe39d9416 > > This has one drawback, we're unable to upload a new TortoiseHg package > if it only includes new Mercurial changesets since the filename will > not change. Bitbucket's file service does not allow you to reliably > upload a new file with the same name. You can upload a new file, but > users will usually D/L the old one.
Which is a problem for Windows Installer as well, since you should change the version number of the msi when you publish a new msi. At least that was my understanding, when I started investigating Windows Installer things a couple of years ago. But maybe I'm wrong and changing only the product id is enough. But at least I would avoid publishing a second msi with the same version number. It's confusing anyway. In that sense, it's an inherent flaw of the current version numbering algorithm anyway. > But I agree it makes sense for the package name to correspond to the > version number that ends up in 'Add/Remove Programs' and the start > menu. Ok. If I take the current version numbering algorithm as a given, we probably could append the product id to the msi filename. At least this would reliably solve the bitbucket file naming problem. Even for the case where neither TortoiseHg nor Mercurial has a new changeset, but only thg-winbuild was changed for a new msi build (the famous package respin problem). We currently have a star for the product id in the WiX sources, which means the wix tools will generate a product id by themselves on each build. However, we will probably sooner or later want to access the Windows installer service database of installed products at runtime anyway, to query the install path of TortoiseHg (there is a Windows API for doing this). For that, we need the product id compiled into the shell extension anyway. Which means we will have to generate a product id ourselves at build time, before the compilation steps, and feed it into both the compilation of the shell extension *and* the WiX sources. Thanks to this we will then also be able to get rid of the dependency of GetTHgProgRoot() on the install path registry key, replacing it with an installer service API call. Point is, if we have that product id GUID available in the build process anyway, we could use it for the msi filename as well. It looks like we could use uuidgen.exe to create a product id at the beginning of the build process: $ where uuidgen C:\Program Files\Microsoft SDKs\Windows\v7.0\Bin\Uuidgen.Exe $ uuidgen 9cc018f9-e680-45e9-8d2c-612a38a4ce77 (this was entered in a cmd.exe console on Windows 7 Ultimate) ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Tortoisehg-develop mailing list Tortoisehg-develop@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tortoisehg-develop
