Johannes Sixt <j.s...@viscovery.net> writes:
> 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.
> 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.
> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
