[cmake-developers] On Mac OS X, the CMake .app filename should not contain the version number ( http://public.kitware.com/Bug/view.php?id=11693#c24958 )

[Clinton Stimpson]

On Thursday, January 20, 2011 09:36:13 am Eric Noulard wrote:
> 2011/1/20 David Cole <david.cole at kitware.com>:
> > Moving to the CMake developer's list, as requested by this bug comment:
> > http://public.kitware.com/Bug/view.php?id=11693#c24958
> > 
> > Comments or thoughts on the topic are welcome...
> > 
> > Please reply here with any further discussion before adding more info
> > to the bug report. Once a consensus is reached here, we'll update the
> > bug again.
> 
> I'm not a Mac user and I'm a poor Windows user :-]
> 
> Now on linux (or other unices) I was puzzled by the /usr/share/cmake-2.8
> thing in fact the vast majority unix software don't come with such version
> mangling. FHS doesn't seems to include recommandation in this area:
> http://www.pathname.com/fhs/.
> 
> Sometimes the version mangling appears when a major update (python2 -->
> python3) arrives and one needs to have both versions installed for
> compatibility reason. In this case, most of the time, the up-to-date
> version is unnumbered and the old compatibility one is renamed with
> version mangling.
> In fact before the big old->new update thing the new version may be
> mangled for a
> while waiting for wider acceptance (Python case).
> 
> Some libs do always have name mangling because the version is really part
> of their name., e.g. glib-2.0.
> 
> Then update-alternative (Debian, Fedora, ?others?) may be used
> to create appropriate links:
> http://www.debian-administration.org/articles/91
> 
> So I vote for no version mangling.
> Or may be an option (default to OFF==no mangling) in order to ease the
> mangling of cmake-2.8
> when cmake 3.0 will be out :-]

I also vote for no version number, but allow the user to change it if they 
want.
It seems that would give the general user a more clear upgrade path.

Clint