Git: Incorrect version number

[ajf8729]

Version 2.21.0 and prior stored the correct version number in the Windows registry. 2.22.0 appears to add additional data, which makes automated packaging and deployment of the software via tools like SCCM more difficult as you can no longer utilize native version number comparison. This can be found via the following:

Get-ItemProperty -Path HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\Git_is1 -Name DisplayVersion | select -ExpandProperty DisplayVersion

Version 2.20.1 stores "2.20.1"
Version 2.20.1 stores "2.21.0"
Version 2.20.1 stores "2.22.0.windows.1"

[dscho]

Version 2.20.1 stores "2.20.1"
Version 2.20.1 stores "2.21.0"
Version 2.20.1 stores "2.22.0.windows.1"

I guess you meant three different versions... ;-)

I think that the DisplayVersion is actually more accurate in v2.22.0: it refers to a precise tag now. This was done as part of git-for-windows/build-extra@08a74309130ccf34a0564a9c1e4fee719b4e9cbb, or at least in a nearby commit, I think.

2.22.0 appears to add additional data, which makes automated packaging and deployment of the software via tools like SCCM more difficult as you can no longer utilize native version number comparison.

If you want to package and deploy software, why do you bother with reading the registry of an already-installed Git for Windows?

I know that Git for Windows itself uses that registry setting, but I have to point out that this is in the _uninstaller_ section, and it is quite obvious that this should be considered "private" data of the InnoSetup-based uninstaller: it can do with that section as it pleases, even changing the data format to JSON for what we know.

The safest way for any 3rd-party tool to detect what version of Git is installed would be to call git.exe version and parse its output, anyway, no?

[ajf8729]

If you want to package and deploy software, why do you bother with reading the registry of an already-installed Git for Windows?

I am reading the registry in order to determine if Git for Windows installed correctly after I install it silently.

The safest way for any 3rd-party tool to detect what version of Git is installed would be to call git.exe version and parse its output, anyway, no?

No, that would require using a completely different method for every program. Using well-known, standard information such as application uninstallation registration data provides a consistent source of information, however, when extra data is included that isn't actually a version number, it makes for difficult comparison. Please see https://semver.org/ for further information.

[dscho]

Using well-known, standard information such as application uninstallation registration data provides a consistent source of information, however, when extra data is included that isn't actually a version number, it makes for difficult comparison.

I am not sure that I like to be limited by you, using uninstaller information for your own purposes, in what I can do to improve Git for Windows. And an improvement it was to make the version information consistent with what is stored in the .exe files.

After all, my main aim in maintaining Git for Windows is not to cater to mis-uses of private data, but to improve Git for Windows itself in any way I can.

And it is a well-known fact that the information in the uninstaller section of the registry is put there by the installer, not so much for your pleasure, but for use by its uninstaller.

And what if we found a totally rad installer and switched from InnoSetup to that totally different installer technology? By your standard you would claim that I cannot do that. You claim control over this project in what it can and cannot do.

I don't think that is appropriate.

If you can find a way to get the information you need _without_ trying to limit how Git for Windows can be enhanced and developed, that's fine by me.

But maybe you just looked in the wrong place, and what you wanted instead was to read the first <h1> line of C:\Program Files\Git\ReleaseNotes.html. Now, _that_ would make sense.

[dscho]

Please see https://semver.org/ for further information.

Git does not use SemVer. That's a pretty well-known fact by now. Besides, Git for Windows' version scheme (e.g. 2.17.1(2)) is _also_ incompatible with SemVer.

And this is just one more inaccuracy in the report...

So I am slowly getting pretty convinced that this ticket needs to be rejected as "not a bug".

[clj84]

I don't think @anthony-fontanez was intending to dictate how you chose to improve your project. To me it was a humble request to project's maintainer to keep their versioning consistent when compared to their previous releases.

I am in a similar situation as him. Out of necessity we have come to rely on the registry, and in rare cases WMI to determine if an application is installed and what version it is. As there's not _really_ a standard for application installs on Windows, unless you use Windows Installer(MSI/MSU/etc), we have to use what information that is as close to _standard_ as we can (Uninstall information in the registry). Then when what we were using is changed, and angry devs complaining the latest version of git isn't installed on their workstation I'll have to go in and figure out why my tools decided to no longer work. Then I discover the semi-standard information I rely on has changed format. Of course, I can easily modify my tools to account for the change. This is just a humble request to keep the versioning consistent going forward, and if at all possible return back to a purely numerical version.

I'm not a developer, so I don't understand how the versioning including "windows" makes the end product better, or prevent you from moving to a different installer so take my opinion/request with a grain of salt.

[ajf8729]

@clj84 is saying exactly pretty much what I was thinking here.

[dscho]

request to project's maintainer to keep their versioning consistent when compared to their previous releases.

We do.

The registry setting of the uninstaller is not a public API. So that does not count.

What counts is what the release notes, the web site, the GitHub releases page, the installer's window title, and all the communication say.

Out of necessity we have come to rely on the registry

That is the bug. If you have a splendid idea how we can provide a consistent interface that is intended to be consumed by users of Git for Windows (as opposed to its own uninstaller), please offer that as a PR.

For example, I would be totally willing to accept a PR that writes the current version in plain text (and in the expected, non-SemVer format) into the top-level directory.

Please don't call a hack a semi-standard. Establish a proper standard instead. And yes, that means you will have to learn to code, at least enough to make the change you so desire. It's not hard to learn.

[sendqueery]

@dscho I think you misunderstand the issue here.

That is the bug. If you have a splendid idea how we can provide a consistent interface that is intended to be consumed by users of Git for Windows (as opposed to its own uninstaller), please offer that as a PR.

This is not the bug. This is how essentially every Windows-based patch management solution operates. As @clj84 said, when it comes to Windows, the registry/WMI are treated as the single source of truth for information about installed software.

After all, my main aim in maintaining Git for Windows is not to cater to mis-uses of private data, but to improve Git for Windows itself in any way I can.

The registry is about as "private" as the phone book as far as data sources go. This is not an improvement for Git for Windows, and is, in fact, counterproductive to the adoption of G4W as it makes it more difficult for administrators to keep their software patched. Also, to _any_ user, admin or no, what benefit is there to having the "windows" tag added to the version field of a Win32 binary?

If you really want it that badly, change the product name field (which also displays the version for some reason) to something like "Git version x.x.x for Windows". (Sidenote: don't do this, as it's still an unnecessary tag. We know it's Windows software by virtue of the fact that WE'RE INSTALLING A WIN32 BINARY ON WINDOWS.)

If you want to package and deploy software, why do you bother with reading the registry of an already-installed Git for Windows?

This is because we also want to keep the software _patched_. When a solution like SCCM looks at its fleet of machines, it has to determine if the current version installed is the same or newer than the version it is attempting to install. How do I compare "2.21.0" with "2.22.0.windows.1" when the comparison is generally done using the .NET version class? How do I compare "2.22.0.windows.1" with "2.23.0.windows.1" in the same context?

Please do some reading before espousing such uninformed viewpoints and using nonstandard versioning. https://docs.microsoft.com/en-us/dotnet/api/system.version?view=netframework-4.7.2

[PhilipOakley]

Just to say that, as Git is primarily a Linux product, the first three numeric elements aren't really in the gift of the Git for Windows team, which is a tricky problem that needs factoring in, along with the need to indicate that the particular variant of the version is for Windows.

Some compromise and tolerance is required when one is not in the driving seat.

[dscho]

@sendqueery thank you for offering your perspective.

I still disagree with the hack you seem to be eager to force me to support. And to be honest, these continued attempts to force your wishes onto a project that you could very possibly contribute more time to help (I cannot recall a single contribution so far, you might want to build up your street cred a bit before trying to spend it) are more likely to have an adverse effect.

If you have a good idea how to accommodate your use case without reintroducing the inconsistency between the version reported by Git itself and the installer and that we fixed by what you call a bug, then let's hear it. This is not the first time I offer to listen to such an idea, and I have yet to hear one.

What won't work is to keep insisting that we should fulfill your wish and re-break the consistency that we fixed earlier. You can argue any way you want, breaking this is not an option.

Speaking of that very consistency, has the idea crossed your mind that you could use the file version of C:\Program Files\Git\cmd\git.exe to verify the installed Git's version? That is, and will remain to be a supported way to query the version, and it even has the 4-digit format you seem to be so keen on:

(Get-Command "C:\Program Files\Git\cmd\git.exe").Version

[sendqueery]

@PhilipOakley I am confused as to why you believe that there's a need to indicate that the variant is for Windows inside of the version number. Change the DisplayName attribute, if you like!

I wholeheartedly suggest that if you're going to build an application/installer for Windows, you should probably use the naming/versioning conventions within that ecosystem. (e.g., you could make the DisplayName "Git for Windows" and the DisplayVersion "2.x.x" and leave it at that.) Most Windows-native applications do not include the multipart version in their name.

@dscho I disagree with you referring to this as a hack. This is literally the mechanism provided within Windows for applications to register themselves, as shown here (the entry for G4W in appwiz.cpl vs. the uninstall data from the registry):

This data is not stored anywhere else on the system, making this the source of truth for this program from a system-level standpoint.

re: file version attribute: Most software management solutions do not have the capability to check the attribute of a specific file for that data. For consistency and simplicity's sake, they instead rely on the data inserted into the registry by the publisher/installer as shown above. This is not a matter of opinion. This is standard practice in this field. (It is also extremely common for the attributes displayed there to differ from the attributes for the individual executables themselves.)

I am not suggesting that you change the output of git version to placate any of us. I _am_ suggesting that you re-evaluate the information written by the installer based on standards in the Windows ecosystem. I _am_ also suggesting that by "fixing" _this_ inconsistency, you have introduced another on the system level.

Even the VersionCompare function (for upgrade checks) in your InnoSetup script appears to rely on a normalized version without text present.

From another angle, why should the file version attribute you suggested above be different from how the program is registered by the installer or what is reported by running git version? According to you, shouldn't those match?

Lastly, my contributions to a project are not reflective of the validity of my or anybody else's stance here. This is not me "forcing my wishes" any more than simply having an opinion is. For you to suggest that is both rude and dismissive, regardless of your own status on this project, and is contrary to the standards for a positive environment set forth in your very own code of conduct.

[dscho]

@sendqueery okay, I stand corrected. Please open a PR to change this as you suggested.

[sendqueery]

@dscho Working on it now. :) While I'm in it, a few additional questions:

1. Do you have any opinions on the naming of the installer .exe itself? If we want to generally strive for more consistency with the output of git version, I might suggest modifying the naming scheme for initial releases like so:
2. Old: Git-2.22.0-64-bit.exe

3. New: Git-2.22.0.windows.1-64-bit.exe or Git-2.22.0.1-64-bit.exe
   I definitely understand wanting to have versioning that matches Git proper, but it's between that and having naming that more accurately indicates the branch from which the installer was built. (In addition, we already do this for releases whose version tags don't end in .1.)

4. Looking at the original PR, I'm trying to figure out why PROD_VERSION was added at all. As we already get $version (and from that, $ver and $displayver) from the output of git version, it should match the ProductVersion attribute of git.exe. As FILENAME_VERSION is set to the value of $version when release.sh creates config.iss, it seems redundant.

The change to provide the correct value for DisplayVersion can also be used to accomplish #1, so it's an easy way to kill two birds with one stone if you're so inclined.

[dscho]

1. Do you have any opinions on the naming of the installer .exe itself? If we want to generally strive for more consistency with the output of `git version`, I might suggest modifying the naming scheme for initial releases like so:


* Old: `Git-2.22.0-64-bit.exe`

* New: `Git-2.22.0.windows.1-64-bit.exe` or `Git-2.22.0.1-64-bit.exe`
  I definitely understand wanting to have versioning that matches Git proper, but it's between that and having naming that more accurately indicates the branch from which the installer was built. (In addition, we already do this for releases whose version tags don't end in .1.)

Well, you made the good point that the tag's naming format does not really constitute a version number, so I reversed my earlier stance.

In that light, I think the current naming scheme for the installers should be more intuitive, no?

1. Looking at [the original PR](https://github.com/git-for-windows/build-extra/pull/235), I'm trying to figure out why PROD_VERSION was added at all. As we already get `$version` (and from that, `$ver` and `$displayver`) from the output of `git version`, it should match the ProductVersion attribute of git.exe. As FILENAME_VERSION is set to the value of `$version` when release.sh creates config.iss, it seems redundant.

Indeed! Dropping the definition of PROD_VERSION and reverting to AppVersion={#APP_VERSION} seems to be the right thing to do.

And I am very sorry that I forgot to give clear advice how to develop/test this. Even though I am sure that you figured out much of it in the meantime, let me try to summarize:

1. install Git for Windows' SDK
2. sdk cd installer
3. sdk build installer to verify that your setup builds a functional installer
4. edit install.iss according to your suggestions
5. sdk build installer, and verify that it does what it is supposed to do
6. commit, push to fork, open PR

Thank you for jumping in!

[PhilipOakley]

@anthony-fontanez et al. For interest, there is a recent blog about Versioning limitations in .NET by Jon Skeet that has some discussions about how difficult thinks can be with multiple common libraries with diamond shaped dependency trees that want different versions from the two sides of the common ancestor.

[jcitarello]

Note that this is also causing some grief in my organization. The program name in the Control Panel also includes this .windows.1 nomenclature, and Puppet's package resource depends on that naming convention.

[dscho]

Note that this is also causing some grief in my organization. The program name in the Control Panel also includes this .windows.1 nomenclature, and Puppet's package resource depends on that naming convention.

@jcitarello so you should be motivated properly to work on a fix. :-)

Maybe you want to coordinate with @sendqueery so as not to step on each others' toes.

[dscho]

Just a gentle reminder that this issue won't move until developers who want to see this issue addressed actually put in more than a bit of conversation.

I laid out what needs to be done here: https://github.com/git-for-windows/git/issues/2223#issuecomment-503524264

[dscho]

Fixed by https://github.com/git-for-windows/build-extra/pull/257