|
Notes |
|
|
(0024647)
|
|
Bill Hoffman
|
|
2011-01-13 11:24
|
|
|
Do you have a patch that adds that support? I don't know much about plist files. |
|
|
|
(0024648)
|
|
Sean McBride
|
|
2011-01-13 11:30
|
|
|
Not at this time. I could attempt such a patch, but not in the short term... a bit swamped currently... |
|
|
|
(0031075)
|
|
James Walker
|
|
2012-09-20 18:10
|
|
|
In my opinion, the lack of a CFBundleName value is worse than the lack of version and copyright information. This makes the app show up with no name in the Activity Viewer utility, for instance. |
|
|
|
(0033903)
|
|
--marc
|
2013-09-26 17:42
(edited on: 2013-09-26 17:52) |
|
|
|
|
(0033909)
|
|
Brad King
|
|
2013-09-27 09:58
|
|
|
Please try out attached 0001-OS-X-Set-CMake.app-bundle-version-fields-in-Info.pli.patch |
|
|
|
(0033910)
|
|
Sean McBride
|
|
2013-09-27 11:04
|
|
That Apple document is wrong. :(
For one, it doesn't make sense that both CFBundleShortVersionString and CFBundleVersion should be the same. For another, you just have to look at the Info.plist of Apple's own applications.
CFBundleShortVersionString is indeed as described, that is, the "marketing version". Pedantically, as per Apple UI, it should only ever be x.y.z but since CMake sometimes gets to x.y.z.w I would go ahead and use all 4 digits there.
CFBundleVersion is meant as an "internal" version number. For svn-based projects, people often use the svn revision. Since it's supposed to be a number though, a git hash is not appropriate. IIRC, it's also supposed to be monotonically increasing. You could use something like YYYYMMDD I suppose.
Cocoa's default 'about box' displays the app's version as "Version <CFBundleShortVersionString> (<CFBundleVersion>)". See attached. |
|
|
|
(0033921)
|
|
--marc
|
2013-09-28 02:33
(edited on: 2013-09-28 02:34) |
|
I think Sean's observation that the Apple documentation is not current with practice is correct.
Vienna RSS reader (http://www.vienna-rss.org [^]) has an example of what works OK on OS X ...
<key>CFBundleGetInfoString</key>
<string>Vienna version 3.0.0 Beta 11 :9d8d6f6:, Copyright 2004-2012 Contributors. See Help/Acknowledgements for list of contributors.</string>
<key>CFBundleShortVersionString</key>
<string>3.0.0 Beta 11 :9d8d6f6:</string>
<key>CFBundleVersion</key>
<string>4790</string>
Note:
1. CFBundleGetInfoString begins with CFBundleShortVersionString.
2. CFBundleShortVersionString is not actually restricted to x.y.z, so x.y.z.w or other string would be OK.
3. CFBundleVersion is some internal, build-specific string. If CMake has some build identifier besides the x.y.z.x, that would make sense to add here ... otherwise a datetime stamp would also be reasonable.
|
|
|
|
(0033931)
|
|
Brad King
|
|
2013-09-30 08:27
|
|
|
|
|
(0033932)
|
|
Brad King
|
|
2013-09-30 08:29
|
|
For reference, CMake's version scheme is:
<major>.<minor>.<patch>[.<tweak|date>]
where a <tweak> of less than 20000000 is considered a release version and otherwise is treated as a <date> of a development version. The components are kept in Source/CMakeVersion.cmake and the date is maintained by a nightly commit update using Source/CMakeVersion.bash. The date is not available for release versions in the current scheme. |
|
|
|
(0033938)
|
|
Sean McBride
|
|
2013-09-30 11:01
|
|
As I reread Apple's docs, I realize I was too harsh to say they are "wrong", "confusing" would be a better word.
Marc, looking at 'Vienna RSS reader' is not necessarily helpful, since 3rd parties often get these things wrong.
Brad, both CFBundleVersion and CFBundleShortVersionString can be x.y.z format; CFBundleShortVersionString pretty much always is, CFBundleVersion is often a single integer. Each of x, y, and z must be integers and not have leading zeros.
CFBundleVersion is meant to be machine-comparible and as such must always be increasing. CFBundleShortVersionString is meant to be prominently user-visible. It's generally always increasing too, but sometimes marketing departments change versioning schemes like MyApp 5.0 -> MyApp 2013.
Neither needs to resemble the other. ex: Preview.app uses 6.0.1 and 765.6.
For CMake, CFBundleShortVersionString should definitely be 2.8.12. If ever you need the .tweak part... well, technically it's not allowed, but as I said, it's the 'marketing' string, so the OS is more forgiving.
You should be more conforming in your CFBundleVersion though, as the OS (and probably MacUpdate.com) do machine-comparisions with it to decide which is the newest version of the app (ex: choosing the app to launch when double-clicking a document). I'm not sure what would be best. It's only user-visible in the About Box (for tech support) so could be a Mac-only scheme. I guess you can't go wrong with YYYYMMDD.
You should also provide:
NSHumanReadableCopyright = "© Kitware Inc., 2013"
LSApplicationCategoryType = "public.app-category.developer-tools"
and remove:
CFBundleLongVersionString
LSRequiresCarbon |
|
|
|
(0033941)
|
|
Brad King
|
|
2013-09-30 11:18
|
|
I don't like CCYYMMDD because:
* Once we use it we can never go with M.m.p[.t] because the major number will never be as large as a date.
* In release versions right now the source code doesn't know its date.
* No one will remember the mapping of date to version.
I'd like to know if the 3-component versions are ordered via integer component-wise comparison like "if(VERSION_LESS)" does, if this is reliable, and ideally if 4 components can be used and still compare correctly. |
|
|
|
(0033943)
|
|
Sean McBride
|
|
2013-09-30 11:33
|
|
Good points. Though I don't see that 'mapping of date to version' comes into play. Remember, CFBundleVersion is just an 'internal build number', not a version the user sees or cares about.
Another problem with YYYYMMDD occurs to me: when you get to CMake 3.0, you may release a patch 2.x release, it should have lower CFBundleVersion than CMake 3.0, but wouldn't using only YYYYMMDD.
I'll sleep on CFBundleVersion, but for all the others, the way forward is clear... you could start with them perhaps? Again:
set:
CFBundleShortVersionString = "2.8.12"
NSHumanReadableCopyright = "© Kitware Inc., 2013"
LSApplicationCategoryType = "public.app-category.developer-tools":
remove:
CFBundleLongVersionString
LSRequiresCarbon
CFBundleGetInfoString |
|
|
|
(0033945)
|
|
Brad King
|
|
2013-09-30 11:49
|
|
Re 0011694:0033943: None of this will happen for 2.8.12. We're already approaching -rc4 and this is not a regression.
See 0001-OS-X-Set-CMake.app-bundle-Info.plist-fields-11694.patch for a draft that uses the 3 components for CFBundleVersion. |
|
|
|
(0033946)
|
|
Brad King
|
|
2013-09-30 13:16
|
|
For reference, here is an old definition of CFBundleVersion:
http://www.dribin.org/dave/blog/archives/2006/08/02/versioning_os_x_apps/ [^]
Quoting the Runtime Configuration Guidelines:
This key specifies the exact build version of the bundle. This
string is usually of the form nn.n.nxnnn where n is a digit and x
is a character from the set [abdf]. The first number is the major
version number of the bundle and can contain one or two digits to
represent a number in the range 0-99. The second and third numbers
are minor revision numbers and must be a single numeric digit. The
fourth set of digits is the specific build number for the release. |
|
|
|
(0034072)
|
|
Sean McBride
|
|
2013-10-07 14:18
|
|
Yes, changing for 2.8.12 is obviously not appropriate. I was using it just as an example value.
0001-OS-X-Set-CMake.app-bundle-Info.plist-fields-11694.patch
I think if you removed the CFBundleVersion part it could be committed (post 2.8.12). CFBundleVersion perhaps needs more thought, as we've discussed... |
|
|
|
(0034076)
|
|
Brad King
|
|
2013-10-08 11:29
|
|
|
Re 0011694:0034072: By "removed the CFBundleVersion part" do you mean the field should be empty or not present at all? |
|
|
|
(0034077)
|
|
Sean McBride
|
|
2013-10-08 11:48
|
|
|
I meant the latter, but checking 2.8.12rc4 I see that it's currently present and empty, so may as well keep it as such. Obviously it should be set eventually, but doing the other stuff first is a good conservative first step. |
|
|
|
(0034079)
|
|
Brad King
|
|
2013-10-08 12:39
|
|
|
|
|
(0035007)
|
|
Brad King
|
|
2014-01-27 14:11
|
|
While most of the Info.plist entries are now populated, CFBundleVersion is still empty due to lack of understanding/agreement of exactly what value should go in there.
I'm removing this issue from the roadmap for CMake 3.0 for now.
|
|
|
|
(0041778)
|
|
Kitware Robot
|
|
2016-06-10 14:28
|
|
Resolving issue as `moved`.
This issue tracker is no longer used. Further discussion of this issue may take place in the current CMake Issues page linked in the banner at the top of this page. |
|
CMakeVersionMissing.png (319,149) 2011-01-13 11:17
0001-OS-X-Set-CMake.app-bundle-version-fields-in-Info.pli.patch (2,387) 2013-09-27 09:58