Notes
(0024644) Bill Hoffman (manager) 2011-01-13 11:16	But then how can you have more than one version installed at the same time? As I recall there was a lengthy discussion about this when I first created it this way. Not sure if it was on the mailing list or the bug tracker...

(0024646) Sean McBride (reporter) 2011-01-13 11:23	You can have more than one version by renaming one or the other, or by placing them in different folders. Renaming a .app does not affect its ability to run. But surely the typical case is that users want the newest version only? I can see that developers would want to test backwards compatibility with older versions, but for everyone else that just needs CMake to build some random project, only the newest version is needed. PS: I do vaguely remember that discussion... I think it was on the list...

(0024649) Bill Hoffman (manager) 2011-01-13 11:34	I would like to find the discussion, because I am pretty sure that what you are asking for, is to go back to the way it was before that discussion...

(0024650) Mike Jackson (reporter) 2011-01-13 11:55	I think I was a part of that discussion. It was way back in November 6, 2007 I believe with a Subject of "Qt version of Cmake". I don't have all of it archived but that should get us close. My Vote is for the removal of the Version from the CMake.app bundle name but there are arguments and precedents both for and against having the version number in the name, but MOST applications do NOT put the Version in the name. On my system of about 50 apps installed only about 5 or 6 have the version number in the name: Adobe products, "A Better Finder Rename XX", and a few other minor programs.

(0024654) Eric Wing (reporter) 2011-01-13 13:52 edited on: 2011-01-13 13:53	I agree that the version number should be removed from the name. Inconsistent names are a pain for automated scripts. Needing multiple versions is an edge case that the majority of people probably don't need to worry about. And it is easily fixable as Sean describes by simply renaming the .app or moving it to another directory. Mac users are very comfortable with this and doesn't require explanation. (By the way, this is another reason drag-and-drop installs are good and installers are bad.) And to underscore Mike's point, Adobe is usually the example of what not to do on the platform :)

(0024955) David Cole (manager) 2011-01-20 09:54	Whatever is decided here should apply to CMake installations across platforms, in my opinion. I've always thought the Windows intaller should default to installing in a "2.8.3" specific path, rather than it's default "2.8" path. That way, I could have side-by-side installs without even having to change the default path when I do the installations. If we remove the version number on the Mac app entirely, should we also remove the "2.8" from the Windows default installation path? Should we also remove the "cmake-2.8" folder name from the Linux install tree? Should it just be "cmake" or "CMake" everywhere without any version qualifications? Or should we do on the Mac what we do now on Windows and Linux: qualify it as CMake 2.8, but omit the patch level... Whatever we choose, it would be really nice if there were a way to say "CMake does it like this" and have that be uniformly true on a cross-platform basis for all the platforms that CMake supports.

(0024956) David Cole (manager) 2011-01-20 09:57	The naming convention exception on the Mac seems to be when there is a suite of apps, the folder name that they all live in is qualified with a version indicator: Examples: iWork '09 Microsoft Office 2008 But then we'd just have the same discussion about the folder name, and whether it should be "CMake 2.8" or "CMake 2.8.3" ... :-)

(0024957) Mike Jackson (reporter) 2011-01-20 10:27	I had about 4 or 5 replies typed here. The conclusion that I came to is that the CMake developers should try to adhere to the principal of least surprise, ie, when someone installs a new version of CMake they would expect all of the current cmake projects to pick up the new version. If we go versioning everything by folder names and application names then drag-and-drop installs are going to fail in the respect that if the user then uses the command line to configure projects, those projects would still use the previous version of CMake unless the user specifically deletes the old version. So for probably the majority of cases installing CMake without the version number in the name is the right choice since things like symlinks that point to "cmake" inside the app bundle wil automatically pick up the new version. For those who need multiple versions (Clearly the minority) they are probably smart enough to create versioned folders for each version of CMake and again since CMake is totally self contained it is easy enough to create these versions. On Windows you are going to have a tougher time with this because you would end up having both the command line and the GUI named "cmake" so I am not really sure what to do on Windows. I would say leave Windows alone as there really isn't any convention on Windows. To summarize Kitware should create an application bundle for OS X simply called "CMake.app" and install into the /Applications folder. If a developer needs side-by-side versions then it is very straight forward to create version folders in /Applications (or anywhere else that CMake is installed). Just my 2 cents. Mike.

(0024958) Bill Hoffman (manager) 2011-01-20 10:32	We should move this discussion to the cmake-developers mailing list. This is not a good place for this type of discussion.

(0035005) Brad King (manager) 2014-01-27 13:49	I forgot to update this issue back when I made this change to fix it: OS X: Drop version number from CMake.app bundle name http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=06b0dbe0 [^]

(0036093) Robert Maynard (manager) 2014-06-02 08:38	Closing resolved issues that have not been updated in more than 4 months.

Issue History
Date Modified	Username	Field	Change
2011-01-13 11:11	Sean McBride	New Issue
2011-01-13 11:16	Bill Hoffman	Note Added: 0024644
2011-01-13 11:16	Bill Hoffman	Assigned To	=> Bill Hoffman
2011-01-13 11:16	Bill Hoffman	Status	new => assigned
2011-01-13 11:23	Sean McBride	Note Added: 0024646
2011-01-13 11:34	Bill Hoffman	Note Added: 0024649
2011-01-13 11:55	Mike Jackson	Note Added: 0024650
2011-01-13 13:52	Eric Wing	Note Added: 0024654
2011-01-13 13:53	Eric Wing	Note Edited: 0024654
2011-01-20 09:54	David Cole	Note Added: 0024955
2011-01-20 09:57	David Cole	Note Added: 0024956
2011-01-20 10:27	Mike Jackson	Note Added: 0024957
2011-01-20 10:32	Bill Hoffman	Note Added: 0024958
2011-07-29 13:33	David Cole	Relationship added	related to 0010938
2011-07-29 15:41	David Cole	Relationship added	related to 0010056
2011-08-12 09:07	David Cole	Relationship added	related to 0012399
2013-11-12 14:27	Brad King	Assigned To	Bill Hoffman => Brad King
2013-11-12 14:27	Brad King	Target Version	=> CMake 3.0
2014-01-27 13:49	Brad King	Note Added: 0035005
2014-01-27 13:49	Brad King	Status	assigned => resolved
2014-01-27 13:49	Brad King	Resolution	open => fixed
2014-01-27 13:49	Brad King	Fixed in Version	=> CMake 3.0
2014-06-02 08:38	Robert Maynard	Note Added: 0036093
2014-06-02 08:38	Robert Maynard	Status	resolved => closed