On 31.03.2010 15:50, Sune Foldager wrote:
> Thanks for comments :)
>
> On 31-03-2010 15:15, Adrian Buehlmann wrote:
>> On 31.03.2010 13:28, Sune Foldager wrote:
>>> +
>>> + def repoversion(verfile):
>>> + globals = {}
>>> + execfile(verfile, globals)
>>> + return globals.get('version', 'unknown')
>>> +
>>> + hgversion = repoversion('../build-hg/mercurial/__version__.py')
>>> +
>>> extra['console'] = [
>>> {'script':'../build-hg/hg',
>>
>> Not sure about using '../build-hg/hg' here (your patch 1). I'll leave
>> this to Steve to decide.
>
> No, it's not optimal, I know. On the other hand, it's not optimal to
> have (sometimes out of date) copies of Mercurial files in thg repo just
> to do builds... so I guess it's a trade-off. These patches were meant as
> RFCs to begin with, btw.
>
>>> 'icon_resources':[(0,'icons/hg.ico')],
>>> 'description':'Mercurial Distributed SCM',
>>> 'copyright':hgcopyright,
>>> - 'product_version':version},
>>> + 'product_version':hgversion},
>>> {'script':'hgtk',
>>> 'icon_resources':[(0,'icons/thg_logo.ico')],
>>> 'description':'TortoiseHg GUI tools for Mercurial SCM',
>>
>> Hmmmmm.
>>
>> With this patch 2, the version resource binary file version of the exe
>> will still be the "binary" Windows version of TortoiseHg then (the
>> binary version is a tuple of four non-negative integers).
>
> Yes.
>
You deleted some parts from the middle of my message here. Namely:
Example of the version resource info of the hg.exe, as produced with
this patch applied (I ran a thg-winbuild thg-stable build with these
patches applied):
>> File version: 1.0.1134.0
>> Product: TortoiseHg
>> Product version: 1.5+62-1b4568d3deb
>>
>> Windows installer doesn't look at the product version string
>> ("1.5+62-1b4568d3deb") when deciding to exchange a files (in minor
>> upgrades). It only looks at the first three numbers of the binary file
>> version ("1.0.1134.0").
>
> Right... so this is just to make the 'product version' if someone
> decides to do a 'version info' on the file, correct. Otherwise there is
> no need to set the product version at all. The file version gets set
> either way.
>
>> (Which -- as a side note -- is one of the reasons why minor upgrades --
>> in Windows installer terms -- can't work with our current sources: we
>> don't reliably count up one of the first three numbers there.)
>
> Right. The situation is even worse for repoman where I package repoman +
> tortoisehg + mercurial. I don't have enough version number elements to
> ensure anything, so I didn't bother putting the mercurial periodic as
> fourth element, like thg does :).
>
>> So, if you are aiming at enabling minor upgrades, I guess you'd probably
>> rather want (hypothetical example):
>>
>> File version: 1.5.1062.0
>> Product: TortoiseHg
>> Product version: 1.0+134-abb41e99f72b
>> for that hg.exe.
>
> Yes, but I wasn't trying that this time around :-). I just wanted the
> 'product version' to be correct, so that value wasn't "lost" (except for
> hg version, hgtk version). The value is completely informal anyway.
The term "correct" is debatable, as I tried to point out in my message.
Your "Product version" does not describe the Product. And we should keep
"TortoiseHg" for "Product", IMHO.
But if you'd like to have it in that strange way (file version/product
version reversed), then feel free to do so if you must.
------------------------------------------------------------------------------
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
