Bug 122375 - the version information embedded in LibreOffice for macOS are broken
Summary: the version information embedded in LibreOffice for macOS are broken
Status: RESOLVED DUPLICATE of bug 74244
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: All Mac OS X (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-12-29 23:57 UTC by dink
Modified: 2018-12-30 06:11 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
version numbers of libre office (2.83 KB, text/csv)
2018-12-30 00:00 UTC, dink
Details
image of the version numbers of recent releases (300.40 KB, image/png)
2018-12-30 00:01 UTC, dink
Details

Note You need to log in before you can comment on or make changes to this bug.
Description dink 2018-12-29 23:57:50 UTC
Description:
the version information embedded into LibreOffice on macOS is broken. 
have a look at this image of a spreadsheet that contains the meta information of the last two dozen releases:
https://ibb.co/PZMC7gM

its immediately obvious that only the information in 'CFBundleGetInfoString' is correct. which is funny, since this key has been deprecated for nearly 10 years, should be removed right now, and is certainly not the right place to have version information.

the CFBundleShortVersionString and CFBundleVersion strings are broken in a funny inconsistent way. 

1.) for dot-zero (x.y.0.p) releases, they are always of a 3-number format, but the last number is ALWAYS wrong:
consider the 6.1.0.3 release which is the 3rd and last build of the 6.1.0 releases. the CFBundleShortVersionString and CFBundleVersion keys should be 6.1.0.3. but it has been set to 6.1.3 which is obviously wrong. the 6.1.3 release didn't happen until 3 months later. not sure what the rationale is here.
2.) for non-dot-zero (x.y.z!=0.p) releases, they are always of a 3-number format, but the last number always contains 2 zeroes instead of the additional point that should seperate the patch level.
consider the current 6.1.4.2 release which is the second build of the 6.1.4 releases. the CFBundleShortVersionString and CFBundleVersion keys should be 6.1.4.2 (or possibly 6.1.4 if you want to ignore the patch level in the short version string). but it has been set to 6.1.4002 which doesn't make sense to me. even if it did make sense, it should be applied consistently, which is the single most important thing about any version number format. its not as important how much sense it makes, but whether you apply it consistently. but you consistently alternate between two different schemes, that in my opinion are broken in different ways. 

in summary, please remove the deprecated CFBundleGetInfoString key and add the sane version numbers stores there to the CFBundleShortVersionString key and/or the CFBundleVersion key. thanks

Steps to Reproduce:
download any and all LibreOffice releases and have a look at the version numbers

Actual Results:
version numbers are not what you expect

Expected Results:
sane version numbers


Reproducible: Always


User Profile Reset: No



Additional Info:
i'll try to attach the full CSV with all version numbers if its possible
Comment 1 dink 2018-12-30 00:00:49 UTC
Created attachment 147892 [details]
version numbers of libre office

version numbers of libre office
Comment 2 dink 2018-12-30 00:01:25 UTC
Created attachment 147893 [details]
image of the version numbers of recent releases

image of the version numbers of recent releases
Comment 3 V Stuart Foote 2018-12-30 06:11:56 UTC

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