Fwd: [tdf-discuss] LibreOffice Version Mismatch/Conflict

[Andras Timar]

2012/3/30 Petr Mladek <pmladek at suse.cz>:
> Andras Timar píše v So 24. 03. 2012 v 16:30 +0100:
>> Hi Petr,
>>
>> See the mail below. Is there a reason why we don't update VERSIONMICRO
>> in solenv/inc/minor.mk?
>
> I am not sure what the version is for. I remember that we updated some
> version in this file and it broke some import/export hacks for backward
> compatibility.

As far as I remember, I introduced the VERSIONMICRO variable before
3.5 feature freeze, and it is used only in File Version field of
Windows executables. The same is true for VERSIONMAJOR and
VERSIONMINOR. It is safe to bump them, when necessary.

>
> For example, see the check for nUPD == 350 in the recent commit
> http://cgit.freedesktop.org/libreoffice/core/commit/?h=libreoffice-3-5&id=befb1c7e26b79ae97d802659f3386882d4044251
>
> I am not sure what exact version string affects getBuildIds() function.
> I just know that we need to be careful with modifying versions in that
> minor.mk :-)

That 350 (and other values at this location) look like the version
string of the Master Workspace (MWS), it is not constructed from
VERSIONMAJOR+VERSIONMINOR+VERSIONMICRO. This version number is
generated by configure script, in line 3383. It is
AC_PACKAGE_VERSION+0 and it is called UPD. AC_PACKAGE_VERSION is
defined by AC_INIT, it is hardcoded in configure.in.
The getBuildIds() function reads UPD (and build id, that is defined in
minor.mk as well).

>
> Ugh, the versioning is a real mess. The versions are defined on many
> locations and used different ways. It is a good candidate for general
> cleanup. Whoever would like to dig into it, please step up.

Now, for the 3.5.3 it would solve the inconsistencies, if you bumped
VERSIONMICRO from minor.mk to 3, and if you displayed 3.5.3.buildid in
About box. That way file versions on Windows, About box version and
MSI version would be the same.

Best regards,
Andras