Just installed the latest and it has the same problem.

Finder shows 6.1.2001

LibreOffice shows 6.1.2.1


Version: 6.1.2.1
Build ID: 65905a128db06ba48db947242809d14d3f9a93fe
CPU threads: 8; OS: Mac OS X 10.12.6; UI render: default; 
Locale: en-CA (en_CA.UTF-8); Calc: group threaded

@Andy : If I open the Finder in Applications, and select LibreOffice.app with the mouse, I don't see any version number displayed, so where are you getting this version number from ?

Alex:

Ah - yes. I forgot not everyone uses the column view in the Finder :-)

So add a step:

0) Select "as Columns" from the View menu.

If you look on the right it shows the icon with information about the file/app. I'll add an attachment with a snapshot.

The problem is the Info.plist is incorrect:

    <key>CFBundleShortVersionString</key>
    <string>6.1.2001</string>
    <key>CFBundleVersion</key>
    <string>6.1.2001</string>

Created attachment 145250 [details]
LibreOffice Finder version

    @Andy - thanks.

    If I switch on column view, I see :

    Version : 6.1.2001

    is that what you mean ?

I have a vague recollection of this having been brought up before with cloph, but not sure when...

@cloph : any opinion ?

From "Technical Note TN2420: Version Numbers and Build Numbers"
https://developer.apple.com/library/archive/technotes/tn2420/_index.html

"The value for a version number or build number must consist only of '.'s and numbers and must begin and end with a number. Each integer value separated by a period is a component of the version. Version numbers and build numbers may have up to three components separated by periods. The total number of characters in your version number or in your build number cannot exceed eighteen characters."

The internet doesn't agree with this document for the CFBundleVersion, but it does for CFBundleShortVersionString, which is displayed everywhere, I guess.

Now quoting the configure.ac build configuration script from the source:

# The CFBundleShortVersionString in Info.plist consists of three integers, so encode the third
# as the micro version times 1000 plus the patch number. Unfortunately the LIBO_VERSION_SUFFIX can be anything so
# no way to encode that into an integer in general.
MACOSX_BUNDLE_SHORTVERSION=$LIBO_VERSION_MAJOR.$LIBO_VERSION_MINOR.`expr $LIBO_VERSION_MICRO '*' 1000 + $LIBO_VERSION_PATCH`

So '6.1.2.1' becomes '6.1.2001' for Apple.

This is a limit on Apples side, so IMHO NOTOURBUG.

Interesting, thanks Jan-Marek.

1) 6.1.0.3 becomes 6.1.3 with the current setup which is clearly incorrect and misleading.

As an end-user, changing this version number the way it does is very confusing.

Since this is a user-facing string, why not just drop the "micro version" instead of munging it? That would make a lot more sense.

2) According to Apple, in the CFBundleVersion:

- The first number represents the most recent major release and is limited to a maximum length of four digits.
- The second number represents the most recent significant revision and is limited to a maximum length of two digits.
- The third number represents the most recent minor bug fix and is limited to a maximum length of two digits.

So the version number being produced here - 6.1.2001 - is invalid.

(ref: https://developer.apple.com/library/archive/documentation/General/Reference/InfoPlistKeyReference/Articles/CoreFoundationKeys.html#//apple_ref/doc/uid/20001431-102364 )


I could go into "why does the project feel it needs a 'micro version' at all", but I won't :-)

We need the micro version for release candidates. E.g. 6.1.3 RC1 -> 6.1.3.1 / 6.1.3 RC2 -> 6.1.3.2
Changing the current versioning in LibreOffice is a No-go, thus, we can't do anything here... Closing as RESOLVED NOTOURBUG

When the "micro" version is 0 and you multiply by 1000 and add the patch number, you get a very misleading version number displayed to the user (6.1.0.3 becomes 6.1.3).

It is a UX bug and you do have control over it - see comment 8. It isn't following the guidelines laid out by Apple.

One solution is not to munge the number when filling in CFBundleShortVersionString (which is user-facing) and instead just drop the "micro" version.

Dropping the micro is not a solution because then nothing differentiates micro releases.

If Apple per comment 8 arbitrarily limits things to three numbers AND the third number can't have more than two digits (which is a ridiculous limit) the only viable workaround is to concatenate micro and RC, under the assumption that we don't release more than 9 micros (usually 7) nor more than 9 RCs (usually 2 to 4), which would give 6.1.32 for 6.1.3.2; this is still confusing because for 6.1.3 seeing 6.1.32 may lead to the impression that the latter would be a higher/later release version, even worse if some version checking mechanism encounters such thing.

That, or we completely change our release numbers versioning, i.e. increment major with every new release every 6 months, which is beyond this bug's outreach.

"...this is still confusing because for 6.1.3 seeing 6.1.32 may lead to the impression that the latter would be a higher/later release version, even worse if some version checking mechanism encounters such thing."

We have that problem now - that's what I'm talking about!

6.1.0.3 is seen as 6.1.3.


"Dropping the micro is not a solution because then nothing differentiates micro releases."

That should be qualified: nothing would differentiate micro releases in this one string.

The end user likely doesn't know about care about the "micro" number. If they do know what it is and need it, they can get it from the About dialog or the Get Info in the Finder (from the CFBundleGetInfoString). They have to do this anyways unless they know how LibreOffice is creating these fake version numbers.

Removing it from this one user-facing string replaces one problem ("Why do I have a more recent version than is released?") with a "better" problem ("How do I find the "micro" number?")

Btw, any idea what the value for the key CFBundleGetInfoString is used for? That contains our full "real" version number, doesn't it?

Naïvely, I would have thought that "CFBundleGetInfoString" exactly is used for something to show to the user, when they "get info".

Responding to myself after a quick googling: Apparently CFBundleGetInfoString has been deprecated almost for ten years... http://www.openradar.me/8600732

Tor:

"Naïvely, I would have thought that "CFBundleGetInfoString" exactly is used for something to show to the user, when they "get info"."

You are correct. CFBundleGetInfoString is used when you select the application and do "Get Info" in the Finder.

Unfortunately it's not what is used when you have the Finder window in column mode. That shows CFBundleShortVersionString.

Commenting due to request: https://bugs.documentfoundation.org/show_bug.cgi?id=120153#c16

Version 6.3.2.2 is displayed in column view as 6.3.2002, so the problem as outlined in the first comment still exists.

Any version that is X.Y.0.Z will be displayed as X.Y.Z which is clearly incorrect.


Version: 6.3.2.2
Build ID: 98b30e735bda24bc04ab42594c85f7fd8be07b9c
CPU threads: 16; OS: Mac OS X 10.14.6; UI render: default; VCL: osx; 
Locale: en-CA (en_CA.UTF-8); UI-Language: en-US
Calc: threaded

*** This bug has been marked as a duplicate of bug 74244 ***