Re: [PATCH/RFC] Makefile: Fix compilation of windows resource file
Johannes Sixt <j.sixt@viscovery.net> writes:
Show 5 quoted lines
> The numbers defined in {FILE,PRODUCT}VERSION statements are intended for
> machine consumption and are always 4 positions (if the source contains
> fewer, they are padded with zeros). They can be used by installers to
> decide whether a file that already exists in the system should be
> overwritten by a newer version.OK, that makes sense. If you package 1.9 (padded as 1.9.0.0) and then 1.9.1 (padded as 1.9.1.0), you can update from 1.9 to 1.9.1 just fine.
Show 8 quoted lines
> Unfortunately, these numbers are visible when the user invokes Properties
> from the context menu of git.exe in the file manager and then switches to
> the "Version" tab. All 4 positions are always listed. Therefore, the user
> will see "1.9.0.0" for the first release of the 1.9 series, which is
> "wrong", because you will call "1.9", not "1.9.0.0", I assume.
>
> With sufficient effort, we could achieve that version 1.9.1 is listed as
> "1.9.1.0". That is still "wrong".
I would not be worried about showing 1.9.1.0 for 1.9.1 and/or 1.9.0.0 for 1.9 at all.
But if the (receiving) system expects these to be monotonically increasing, I suspect the script I posted would not "work well" under that expectation. When you package 1.9.2.g43218765.dirty, that would become "1.9.2.0", and become indistinguishable from the package taken from v1.9.2 tag, which is not good at all. So the script should strip [0-9]*\.g[0-9a-f]*\(\.dirty\)? from the end first.
But even without complications from the "N-commit after the tag" it won't "work well" if you cut packages from anything that is not tagged anyway. The only thing we know about any package taken from the tip of 'master' past v1.9 is that it is newer than the package taken from v1.9 tag. Sometimes it should be considered newer than a package taken from v1.9.x tag (i.e. the contents of the maintenance relase is fully included in 'master'), but not always (i.e. the tip of 'master' when the package was made may contain up to v1.9.3 but v1.9.4 may be newer than that).
If you truncate down to only two, like your patch does, anything past v1.9 and before v1.10 (or v2.0) would have 1.9.0.0 and that is no worse than giving 1.9.3.0 for v1.9.3 and giving 1.9.0.0 for anything based on 'master'. Your user may have installed a package made from v1.9.1 and would want to update to the one taken from 'master' when it contained everything up to v1.9.3---under my earlier "take numbers" approach, we would be "updating" from 1.9.1.0 to 1.9.0.0, which does not look like updating at all to the system. The installers can use this to decide "a file that already exists in the system" is newer, which is wrong, if I am reading your earlier explanation corretly.
With your "we just take the first two numbers always", you would be sidegrading between two 1.9.0.0, which may fare better.
Show 37 quoted lines
> Since we can't get this display right, I suggest that we just punt (as per
> my patch). That should work out nicely because we can fairly safely assume
> that there are no installers around that look at these particular version
> numbers.
>
> BTW, that same "Version" tab will have another entry, called "Product
> Version" later in the list. This one lists the string that we pass in
> -DGIT_VERSION (see quoted context below). It is the truely correct version
> that *users* should be interested in.
>
>>
>>> diff --git a/Makefile b/Makefile
>>> index b4af1e2..99b2b89 100644
>>> --- a/Makefile
>>> +++ b/Makefile
>>> @@ -1773,7 +1773,7 @@ $(SCRIPT_LIB) : % : %.sh GIT-SCRIPT-DEFINES
>>>
>>> git.res: git.rc GIT-VERSION-FILE
>>> $(QUIET_RC)$(RC) \
>>> - $(join -DMAJOR= -DMINOR= -DPATCH=, $(wordlist 1,3,$(subst -, ,$(subst ., ,$(GIT_VERSION))))) \
>>> + $(join -DMAJOR= -DMINOR=, $(wordlist 1,2,$(subst -, ,$(subst ., ,$(GIT_VERSION))))) \
>>> -DGIT_VERSION="\\\"$(GIT_VERSION)\\\"" $< -o $@
>>>
>>> ifndef NO_PERL
>>> diff --git a/git.rc b/git.rc
>>> index bce6db9..33aafb7 100644
>>> --- a/git.rc
>>> +++ b/git.rc
>>> @@ -1,6 +1,6 @@
>>> 1 VERSIONINFO
>>> -FILEVERSION MAJOR,MINOR,PATCH,0
>>> -PRODUCTVERSION MAJOR,MINOR,PATCH,0
>>> +FILEVERSION MAJOR,MINOR,0,0
>>> +PRODUCTVERSION MAJOR,MINOR,0,0
>>> BEGIN
>>> BLOCK "StringFileInfo"
>>> BEGIN
Ramsay Jones
