-
-
Notifications
You must be signed in to change notification settings - Fork 30k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Windows Installer Product does not include micro version in display name #75286
Comments
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:
Proposed alternatives for the value of product version:
Side note: |
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. |
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.
"display version" is set most of the time. "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 |
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 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 C) Suggest the default install dir is |
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 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.
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). |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: