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

[Petr Mladek]

Andras Timar píše v Pá 30. 03. 2012 v 22:29 +0200:
> 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.

Good to know. I do not remember any mail about this new variable. :-)
Why was it introduced and how is it supposed to be used?

> > 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).

Ah, it is even bigger mess than I expected.


> > 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.

The question is what number we want to use for the buildid.

In the past, the windows installer used 3.5 version and we needed to use
the micro version in the buildid. We used the following scheme
to make it predictable:

      bugfixrelease micro + 0 + rcnumber

, so we get:

      buildid 101 for 3.5.1-rc1
      buildid 102 for 3.5.1-rc2
      buildid 201 for 3.5.1-rc1

If we use what you suggest, we will get in the about dialog:

      3.5.1.101 for 3.5.1-rc1
      3.5.1.102 for 3.5.1-rc2
      3.5.2.201 for 3.5.2-rc1

IMHO, it is ugly because the micro version is there twice.

How the windows installer distinguish the build version these days? Does
it use the VERSIONMAJOR+VERSIONMINOR+VERSIONMICRO? Could we restart
buildid for each bugfix release and get the following?

	buildid 1 for rc1
        buildid 2 for rc2

The we could have in the about dialog what we use now:

      3.5.1.1 for 3.5.1-rc1
      3.5.1.2 for 3.5.1-rc2
      3.5.2.1 for 3.5.2-rc1


Best Regards,
Petr