Each Windows installation has a “product version”.

The Windows installer python-3.6.2.exe has product version "3.6.2150.0"  (accessible with context menu / Properties / Details).

This causes at least 2 problems:
 - Automated software inventory relies on product version and therefore does not detect version 3.6.2
 - Microsoft installation guidelines require the first three fields to be smaller than 256.

Proposed alternatives for the value of product version:
- "3.6.2.0" to indicate the final release build.
- "3.6.2.150" to indicate the build number. The build number may be higher than 256, but this is unusual for a final release.



Side note: 
This is a sub-problem of http://bugs.python.org/issue31077

Screenshot of Product Version 3.6.2150.0

Can you link to those guidelines please? Microsoft release plenty of software with version numbers over 256.

Also, since people already rely on the current scheme, we'd need a very compelling reason to break them. I don't believe you've made that case yet.

The docs [1] are clear that this property must be of the form major.minor.build. It can include at least one additional field, which the installer ignores. The major and minor version numbers can be up to 255, and the build number can be up to 65535. Python's ProductVersion property complies with this:

    db = msilib.OpenDatabase('core.msi', msilib.MSIDBOPEN_READONLY)
    v = db.OpenView("select * from Property where Property='ProductVersion'")
    v.Execute(None)
    r = v.Fetch()

    >>> r.GetString(2)
    '3.6.2150.0'

It would be unorthodox to use the build version field for Python's micro release version number. I don't see why it's really important since micro releases are ABI compatible for in-place upgrades.

[1]: https://msdn.microsoft.com/en-us/library/windows/desktop/aa370859

Hi Guys,

The reason I raise the original is for all those configuration management tools which need the version number.

In the uninstall registry is very much an inconsistent.
*Anything with a Display Name in the registry (name in the GUI) will be listed.
* Their are two places for version information.
** 1 "large int (DWORD) version number" called "version" store across several integers in the registry, which supports <0-255>.<0-255>.<0-65535> this is not visible in the GUI.
** display version, which is a string, and can be set to anything, this is visible in the GUI.

"display version" is set most of the time.
"large int version number" not always

"large int (DWORD) version number" I have actual see software which as created this as a text string, which is just wrong. e.g. Google Chrome, however Google Update Helper does the right thing.

People see the "display version" so this needs to match the version of python.  I would expect most configuration management tools to use "display version" before "large int (DWORD) version number"

The following is based on installing python 3.6.2 (3.6.2150 not sure what this means)

display name should be "Python 3.6 (64-bit)" if you wish to encourage  only single version of 3.6 to be installed. or "Python 3.6.2 (64-bit)" if you wish to allow many versions of 3.6 to be installed. "3.6" matches closer to what happens in the unix/linux world (/usr/lib/python2.6).
 
display version string should 3.6.2 or 3.6.2.2150 never 3.6.2150 
"large int (DWORD) version number" should not be set, but you could force it to 3.6.2 given your unlikely to go higher than 255.255.65535 the automatic builds might not like doing this, might be easier not to set it.

The python 3.5.3 (64-bit) installer currently adds most of the components installed in the "MACHINE" Registry all but 1 item (2 entries)

"python 3.5.3 (64-bit)" software entry which it places in both the 32 bit and also the 64 bit registry.  It should be in the "MACHINE" Registry and only in the 64 bit registry, which is the default for 64 bit installer. 

For example a 32 bit installer would place "python 3.5.3 (32-bit)" only in the 32 bit part of the registry.

Because this entry "python 3.5.3 (64-bit)" is the USER part of the registry, only the user who installs python can see that it is installed.

There's an existing bug for the registration going to the wrong place. It requires changes to the Wix toolset to resolve. No need to conflate it with this issue.

As far as I can tell, the problem here is just the version string displayed in Programs and Features? Correct?

Steve, yes: from my point of view, the version in "Programs and Features" should be  3.6.2 or 3.6.2.0 or 3.6.2.150. 


Eryk, thank you for your explanation - I had a wrong memory about the third field in ProductVersion to be the micro version and learned something. 


If that would be helpful, I could change the title of this issue.

To Summaries
A)
Name/DisplayName "Python 3.X (64-bit)" or "Python 3.X.Y" (64-bit) "Python 3.X (64-bit)" would match the install directory which is \Python3X (this should be \Python3.X)

Display Version should start with 3.X.Y or 3.X.Y.<build number>

version DWORD in the registry does not need to be set but if set would need to be 3.X.Y
B) Registry being placed in in the wrong location
HKU\<User-SID>\Software\Microsoft\Windows\CurrentVersion\Uninstall\{GUID}
should be going into
HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall

C) Suggest the default install dir is
"c:\Program Files\Python3.6" instead of "c:\Program Files\Python36"

This issue is about A.

B has a separate issue. C will not be changed. Please don't bother bringing them up again here, it's just a distraction.

FYI, the 3rd field is Field3Value, defined in "PCbuild/python.props" as the value `MicroVersionNumber*1000 + ReleaseLevelNumber*10 + ReleaseSerial`. It gets set as the FIELD3 macro in "PCbuild/pyproject.props", which gets used in the definition of the PYVERSION64 macro in "PC/python_ver_rc.h". PYVERSION64 is used as the FILEVERSION and PRODUCTVERSION in the resource files. But note that the "FileVersion" and "ProductVersion" string values are instead based on the PY_VERSION macro, which is defined in "Include/patchlevel.h", which for release builds is the normal "major.minor.micro" string. 

In "Tools/msi/msi.props", Field3Value is used in the "Version" variable as follows: "$(MajorVersionNumber).$(MinorVersionNumber).$(Field3Value).0", which is used for all of the MSIs and the bundle. 

> Display Version should start with 3.X.Y or 3.X.Y.<build number>

Is this referring to the above MSI version value, which gets displayed in the version column in "Programs and Features"? I'm far from an expert with MSI. This is Steve's wheelhouse, and he'll correct me if I'm wrong, but I think it's important that at least one of the first 3 fields changes for a normal update. In the development cycle, it's thus up to the Field3Value, as the release level (10, 11, 12, 15) and serial (0, 1, 2, ...) are incremented. In that case the 3rd field cannot be just the micro version number.

Eryk is correct, the displayed version number is the one that determines whether to update existing files or not, and the fourth field is (IIUC) not used for this by WiX (our installer technology). We also cannot override the displayed version using this technology.

It's also worth noting that the Windows Store package is similarly limited, and has a slightly different scheme again (I forget why, but if it could've been identical then it would have been - I guess it was because we cannot do prerelease versions there).

So the only real fix is for someone to rewrite the entire installer using a new technology. I'm not volunteering to do that, and as long as I'm the build manager I'm not going to accept any PRs doing it (though that's not to say that I won't do it myself, just that I'm not currently considering unsolicited contributions and doing it would be a waste of your time). Consistency between releases is more important right now - it's not difficult to find the version number for a particular install if needed (just look at its file properties).