Problem description: CFShortBundleVersionStrings are incorrect on both x86 and x86_64 OSX builds Steps to reproduce: 1. mount Libreoffice 4.2*.dmg 2. open Libreoffice.app/Contents/Info.plist 3. Current behavior: <key>CFBundleShortVersionString</key> <string>4.2.4</string> Expected behavior: <key>CFBundleShortVersionString</key> <string>4.2.0.4</string>
This line 1408 in LibreOffice.app/COntents/Info.plist
I was too lazy to file a bug for this one.
*** Bug 74907 has been marked as a duplicate of this bug. ***
Still applicable in the latest 4.2.1.1 release, which reads as 4.2.1001
Still applicable in 4.2.2.1 RC1. It reads as 4.2.2001
the version is defined as follows: # 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 this is a limitation that needs a workaround, so cannot fix/worksforme.
http://cgit.freedesktop.org/libreoffice/core/commit/?id=bbbc51e931c3a7018f2f19f61fa823190ee6fbb1 btw. closing.
Translation: MAS wants 3 or less integers separated by a dot. That means to get the build info into that system LO uses 4.2.2002 which then would be the 2nd build for version 4.2.2. indeed worksforme. Took me sometime but now I get it. thanks for searching this link christian.
reopening. The code fails for the .0 releases. 0*1000 still is 0, so 4.3.0.1 would then identify as 4.3.1 and rc2 as 4.3.2 and that would be very wrong :-) As there are many Applications that use more liberal formatting of the version: If anyone finds an Appstore-Listed application that uses more than three integers (maybe even letters), then the limit can be reverted again as well.
Has this been resolved by chance? Can we close as WFM?
Still affected in 4.4.0.x, which reads as 4.4.3. But as long as 4.4.1003 > 4.4.3, worksforme.
Christian, are you still on this? Do you have an idea how this could be solved?
Setting Assignee back to default. Please assign it back to yourself if you're still working on this issue
*** Bug 122375 has been marked as a duplicate of this bug. ***
any progress on this? please fix at least the CFBundleVersion entry.
*** Bug 120153 has been marked as a duplicate of this bug. ***
Clearer title and lowering importance
This stackoverflow answer https://stackoverflow.com/a/37178198/6591 indicates that only 3 numbers are allowed for the short version
even Apple's own apps have more than 3 components: /Applications//Safari.app ID: com.apple.Safari BV: 15609.1.20.111.8 SVS: 13.1 EXE: Safari /System/Applications/Mail.app ID: com.apple.mail BV: 3608.80.23.2.2 SVS: 13.4 EXE: Mail /System/Applications/Maps.app ID: com.apple.Maps BV: 2439.24.10.29.57 SVS: 2.1 EXE: Maps the only real technical "restriction" is that the CFBundleVersion should be only points and numbers and monotonically increasing because if multiple versions are installed the copy with the numerically highest CFBundleVersion will be launched
You're talking about CFBundleVersion, not CFShortBundleVersionString. The CFShortBundleVersionString is user-visible, therefore this results in a UX bug. Please see the extensive discussion in the bug I filed that was closed as a duplicate: https://bugs.documentfoundation.org/show_bug.cgi?id=120153
> You're talking about CFBundleVersion, not CFShortBundleVersionString. as i said above in the post from 2018-12-30 10:55:25 UTC at least CFBundleVersion should be fixed > The CFShortBundleVersionString is user-visible, therefore this results in a UX bug. not true since the two zeroes that are inserted (and which destroy any meaning of the version number) are obviously longer than the single dot which is omitted. proof that proper CFShortBundleVersionString doesn't result in any UX bug in any of the 3 methods to view versions numbers in the Finder: https://i.postimg.cc/0rMrjGd3/Screenshot-2020-05-19-at-22-20-56.png https://i.postimg.cc/Thz1DytP/Screenshot-2020-05-19-at-22-21-03.png https://i.postimg.cc/vc5BLQKt/Screenshot-2020-05-19-at-22-21-17.png
Proof that it does: https://postimg.cc/N9gTjCdG See my previous report. In column mode it's wrong.
> See my previous report. In column mode it's wrong. .... this is what this bug report is about. it should be '6.4.2.2' not '6.4.2002'. your screenshot just proves that. your last few comments said the bug ('6.4.2002' instead of '6.4.2.2') cannot be fixed because if it would be fixed it would result in a problem. there is no proof of that.
Have anyone checked if the limits of Apple are enforced? I just see that Spotify has this as the CFBundleShortVersionString: 1.1.31.703.g256add22 And that is shown by Finder just fine
I submitted a patch to gerrit to fix the issue that 6.4.0.3 shows up as 6.4.3 https://gerrit.libreoffice.org/c/core/+/94623/1 I now see that the recommended would actually have been to use the three version identifier for ShortVersionString as that should be for released versions, while the BundleVersion can have all four, the fourth is just ignored if it exceeds three (assume the same happens for the short string) But, I think the current patch is sufficient CFBundleShortVersionString (String - iOS, macOS) specifies the release version number of the bundle, which identifies a released iteration of the app. CFBundleVersion - used for unreleased (so LO would use four integers) While developing a new version of your app, you can include a suffix after the number that is being updated; for example 3.1.3a1. The character in the suffix represents the stage of development for the new version. For example, you can represent development, alpha, beta, and final candidate, by d, a, b, and fc. The final number in the suffix is the build version, which cannot be 0 and cannot exceed 255. When you release the new version of your app, remove the suffix. You can include more integers but the system ignores them. https://developer.apple.com/library/archive/documentation/General/Reference/InfoPlistKeyReference/Articles/CoreFoundationKeys.html#//apple_ref/doc/uid/20001431-102364 https://developer.apple.com/documentation/bundleresources/information_property_list/cfbundleversion?language=objc
Eivind Samseth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/3a028418190790c3bbaf6e505ff55b7bb8c0b474 tdf#74244 Fix version info shown for major release candidates It will be available in 7.0.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
thanks i can confirm this seems to be fixed in the newest builds. lets keep this closed, if any additional issues come up we can open a new issue.
Great, this was finally tackled. Thanks eisa01. Attaching screenshots for 6.4.x and 7.0.x.
Created attachment 161679 [details] 6.4
Created attachment 161680 [details] 7.0
Apple does enforce that both these version strings in the Info.plist consist of a period-separated list of at most three non-negative integers when one submits an app to the Mac App Store. Thus the "fix" for this non-bug broke the submission of LibreOffice Vanilla to the App Store.