This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: Windows Installer Product does not include micro version in display name
Type: enhancement Stage: resolved
Components: Installation, Windows Versions: Python 3.10, Python 3.9, Python 3.8
Status: closed Resolution: not a bug
Dependencies: Superseder:
Assigned To: Nosy List: Markus Kramer, damon-atkins, eryksun, paul.moore, steve.dower, tim.golden, zach.ware
Priority: low Keywords:

Created on 2017-08-02 10:04 by Markus Kramer, last changed 2022-04-11 14:58 by admin. This issue is now closed.

File name Uploaded Description Edit
3.6.2.png Markus Kramer, 2017-08-02 10:11 Product Version 3.6.2150.0
Messages (13)
msg299651 - (view) Author: Markus Kramer (Markus Kramer) Date: 2017-08-02 10:04
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:
- "" to indicate the final release build.
- "" 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
msg299652 - (view) Author: Markus Kramer (Markus Kramer) Date: 2017-08-02 10:11
Screenshot of Product Version 3.6.2150.0
msg299658 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2017-08-02 13:54
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.
msg299676 - (view) Author: Eryk Sun (eryksun) * (Python triager) Date: 2017-08-02 22:41
The docs [1] are clear that this property must be of the form 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'")
    r = v.Fetch()

    >>> r.GetString(2)

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.

msg299715 - (view) Author: Damon Atkins (damon-atkins) Date: 2017-08-03 16:52
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 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.
msg299716 - (view) Author: Damon Atkins (damon-atkins) Date: 2017-08-03 17:06
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.
msg299717 - (view) Author: Damon Atkins (damon-atkins) Date: 2017-08-03 17:09
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.
msg299721 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2017-08-03 19:12
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?
msg299757 - (view) Author: Markus Kramer (Markus Kramer) Date: 2017-08-04 18:29
Steve, yes: from my point of view, the version in "Programs and Features" should be  3.6.2 or or 

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.
msg299758 - (view) Author: Damon Atkins (damon-atkins) Date: 2017-08-04 19:07
To Summaries
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
should be going into

C) Suggest the default install dir is
"c:\Program Files\Python3.6" instead of "c:\Program Files\Python36"
msg299784 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2017-08-05 13:55
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.
msg388978 - (view) Author: Eryk Sun (eryksun) * (Python triager) Date: 2021-03-18 00:53
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.
msg389047 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2021-03-18 22:59
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).
Date User Action Args
2022-04-11 14:58:49adminsetgithub: 75286
2021-03-18 22:59:52steve.dowersetstatus: open -> closed
resolution: not a bug
messages: + msg389047

stage: resolved
2021-03-18 00:53:40eryksunsetmessages: + msg388978
versions: + Python 3.8, Python 3.9, Python 3.10, - Python 3.6, Python 3.7
2017-08-05 13:56:36steve.dowersettitle: Windows Installer Product Version 3.6.2150.0 Offset By -> Windows Installer Product does not include micro version in display name
2017-08-05 13:55:57steve.dowersetpriority: normal -> low
versions: + Python 3.7
messages: + msg299784

components: + Installation
type: behavior -> enhancement
2017-08-04 19:07:06damon-atkinssetmessages: + msg299758
2017-08-04 18:29:46Markus Kramersetmessages: + msg299757
2017-08-03 19:12:35steve.dowersetmessages: + msg299721
2017-08-03 17:09:39damon-atkinssetmessages: + msg299717
2017-08-03 17:06:50damon-atkinssetmessages: + msg299716
2017-08-03 16:52:56damon-atkinssetmessages: + msg299715
2017-08-02 22:41:48eryksunsetnosy: + eryksun
messages: + msg299676
2017-08-02 13:54:36steve.dowersetmessages: + msg299658
2017-08-02 10:11:17Markus Kramersetfiles: + 3.6.2.png

messages: + msg299652
2017-08-02 10:04:48Markus Kramercreate