Eryk Sun <eryk...@gmail.com> added the comment:
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. ---------- versions: +Python 3.10, Python 3.8, Python 3.9 -Python 3.6, Python 3.7 _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31103> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
