Stable OS X releases should use Julia.app not Julia-X.Y.Z.app name for application bundle

[nanoant]

Currently each Julia release including patch releases add complete version suffix to Julia-X.Y.Z.app OS X application bundle name contained in .dmg distribution package.

I honestly think this is really bad idea for stable (and patch) releases because:

1. Upgrading Julia with patch release isn't as simple as overwriting older Julia.app
2. Command line symlinks need to be updated each time we install patch release.
3. There no way to assume usual placement of julia command. This matters me a lot, since TextMate Julia.tmbundle tries to assume some well known location of this command, but since it depends on currently installed version I simply can.

So hereby I propose that:

1. Stable releases use just Julia.app, so we can simply assume that usually julia command will be in /Applications/Julia.app/Contents/MacOS/julia
2. Only development releases or manual builds use version suffix, so they can be installed side-by-side with stable releases

Finally there should be indeed a popup asking to install /usr/local/bin/julia symlink pointing inside Julia.app when running the application. Something like:

"Do you want to make julia command to be available from any command line, creating symlink to /usr/local/bin/julia?"

This is somehow related to issue #8733.

P. S. We could also consider using Sparkle integration in Julia.app so it checks for new version and auto-updates itself.

[nalimilan]

Until Julia is backward-compatible from X.Y to X.(Y+1), it could make sense to still allow parallel installation of 0.3 and 0.4 (thus calling the image Julia-X.Y.app).

[StefanKarpinski]

I don't install Julia this way so it's of limited Impact to me, but including the version numbers in the app bundle seems pretty sensible and let's people use multiple versions at the same time. It might be nice to automatically create julia-x.y links for running specific versions from the command line too. I do that pretty regularly so I imagine others might as well.

[nanoant]

Okay, I can understand that regular some users may want to have Julia-X.Y.app eg. Julia-0.4.app and Julia-0.3.app once 0.4 is stable to port potentially incompatible code to new stable release. But honestly I don't see any reason to have Julia-0.3.6.app and Julia-0.3.7.app separate names for patch releases.

Julia developers, package maintainers or hackers are still free to rename the Julia.app to anything they want adding adding some suffix. However for regular users having each patch release land in separate location may be confusing also they need to remember to update paths on each path release, that happen pretty often. i.e.:

1. TM_JULIA TextMate env variable
2. Some symlinks pointing to julia cmd, etc. etc.

Finally let's take an example of other apps like Mathematica, R or Xcode, they all don't put any version suffixes to their names, because in most cases user wants just most recent release, period. And if anyone want to have BOTH version, Finder offers option to keep both upon overwrite popup.

So I propose to at least get rid of .Z patch number from the name if not removing the version completely at all.

[StefanKarpinski]

Patch releases don't make sense. They should be completely compatible.

[ViralBShah]

This makes sense. Applications on OS X usually don't have any version numbers. I think having the major version number in the name and getting rid of the patch level is a good tradeoff.

It would be nice to have a PR for sparkle integration too. I hope it doesn't require users to install Sparkle, but if it gets bundled into Julia, and prompts users for new releases, that would be great.

[tkelman]

One advantage of including the full version in the name is nothing overwrites, and you don't have to manually uninstall the old version every time you update. Some sort of optional self-updating framework, at least for patch releases, might start to make sense though.

[nanoant]

It would be nice to have a PR for sparkle integration too. I hope it doesn't require users to install Sparkle, but if it gets bundled into Julia, and prompts users for new releases, that would be great.

@ViralBShah No Sparkle is just a framework (library) with some minimal API that checks for some entries in RSS xml at given URL known to the app. It does the check every time it is run, or once a while or never, depending on user's decision. Once there is new version it can popup an information and changelog. It can use the same .dmg file to do automatic update, so whole process is really straightforward. I did integrate Sparkle in few apps, so give me day or two and I prepare PR.

One advantage of including the full version in the name is nothing overwrites, and you don't have to manually uninstall the old version every time you update.

@tkelman You mean you do have to uninstall old version. If you drag Julia-0.3.7.app into /Applications and Julia-0.3.6.app is already there, then you will end up with two Julias, until you manually delete one of them (old one). Next you need to ensure all your scripts, symlinks etc. etc. point to new Julia. Every time new release comes.

[tkelman]

then you will end up with two Julias, until you manually delete one of them (old one).

That seems entirely expected to me, after installing two different versions?

The list of files isn't always going to be exactly the same between different patch versions, so overwriting in-place could lead to leaving behind old files that might have been deleted. A clean upgrade would uninstall first then install the new version, either separately or in the same location.

[nanoant]

The list of files isn't always going to be exactly the same between different patch versions, so overwriting in-place could lead to leaving behind old files that might have been deleted.

I am sorry, but this is completely false. Using .dmg package if you just drag Julia.app into /Applications and there there is another Julia.app then Finder pops up a dialog asking what to do. Then if you choose to Replace then there will be absolutely NO LEFTOVERS. As Finder does not merge these .app folders, but replaces one with the other.

[ViralBShah]

I believe OS X used to do the merge in older versions, or at least people have told me that in the past anyways. I always religiously delete the old app before installing a new one, thinking that to still be true.

[nanoant]

We can just attribute this behavior to Finder not whole OS X. Anyways, I just checked how 10.5 Leopard behaves, I still have VM with Leopard and it does not merge, but replaces content.

So the behavior you described could exist in very very old versions of OS X Finder.

Moreover since 10.8's Gatekeeper, Finder simply must replace when dragging app onto existing one. Otherwise any leftover file will invalidate Gatekeeper signature.

[tkelman]

Using .dmg package if you just drag Julia.app into /Applications and there there is another Julia.app then Finder pops up a dialog asking what to do. Then if you choose to Replace then there will be absolutely NO LEFTOVERS.

Ah, that's good. I'm not an OS X user so was unaware of that feature. What are the other options it gives you other than "Replace"?

[nanoant]

FYI: Keep Both keeps the old one in the original location and places new one adding -copy suffix.

[stevengj]

I agree with removing the version number from the filename, which is not idiomatic on MacOS. As an added benefit, this means that you won't need to re-run Pkg.build("IJulia") each time you upgrade Julia.

[tkelman]

It sounds like the patch number should be fine to remove. But I agree with @nalimilan above that removing the rest of the version numbers would maybe be counterproductive as long as it's going to be common to have multiple incompatible Julia versions installed simultaneously.

[stevengj]

@tkelman, I don't agree. The user can always rename Julia.app themselves, so in no sense are we not allowing them to have multiple versions of Julia installed.

[rsrock]

+1 to ditching the version number entirely.

[ViralBShah]

@stevengj Most users do not rename the applications. If you rename, all bets are off. Many apps do not have version numbers, but MS Office for example is installed as Microsoft Office 2011 so that by default, if users install a newer version, old versions can co-exist. But this is the exception more than the norm on OS X.

I am ok to go with either case. It really may not matter as much as we think it will.

[mbauman]

I like the idea of just using the major/minor Julia-X.Y.app. It composes very nicely with using Sparkle for nonbreaking patch updates, and I think it's important to allow easy (no-rename) simultaneous installs of incompatible versions. Think about how the install instructions would look for a breaking release — do we really want to have an extra step "rename your existing Julia.app to Julia-old.app, which you should use until you manage to make your existing code compatible with the new version."

Perhaps we can re-evaluate when we hit 1.0 and the minor version updates become backwards compatible (assuming we keep following SemVer).

[rsrock]

I just checked my Applications folder. I have 121 items there, and 5 of them have version numbers. Most of these are cross-platform apps. (Actually, now it's 4. I had Matlab in there, and I've migrated my lab code away from Matlab a couple of years ago. Deleted, and recovered 7 gigs.)

Interestingly, one of these is Apple's iWork '09. The current Pages.app, Keynote.app etc. are all in the top level folder. If you install the older versions, they end up in an iWork '09 folder, but are named Pages.app, etc. without the version number.

[mbauman]

How many of those 116 unversioned applications release backwards-incompatible updates with respect to user data (and user code, if they run code)?

The iWork model is interesting. I could see Julia always installing the latest release as Julia.app, and renaming any previous Julia.app to Julia-$VER.app, but it'd require an installer and would increase the installation complexity dramatically. Can Sparkle do this?

[stevengj]

@mbauman, I don't see the difficulty here. Renaming files is not hard, it is an everyday task that any user is familiar with. If you want to keep your old Julia, rename it (or the new Julia) instead of copying over it. If you accidentally overwrite your old Julia and want to go back to it, you can always download it again. Why would this be hard for people to comprehend?

[mbauman]

It's not complicated at all, but our current installation is so wonderfully simple that even one extra step is a substantial increase. This is just my preference.

[stevengj]

@mbauman, our current installation requires you to re-run Pkg.build("IJulia") after every installation, unless you rename it to have the same name, if you are using IJulia. Similarly for any other references to the julia path. This is not simple, it is not intuitive, and it is not easily discoverable.

In contrast, defaulting to installing Julia with the same name, and requiring a manual rename in the (rare for non-developers) cases where you want multiple versions of Julia installed, is much simpler and more importantly it is more comprehensible and easily discoverable (since the OS tells you you are replacing a file with the same name and offers the option of a rename).

[tkelman]

our current installation requires you to re-run Pkg.build("IJulia") after every installation

That part would be fixed, for patch-increment upgrades, by just removing the patch digit. Considering 0.3 and 0.4 will have different Pkg.dir anyway, you'll need to reinstall all your packages for a minor-increment upgrade, even if Julia doesn't move.

[ViralBShah]

I think removing the patch digit is the right thing to do here.

[stevengj]

+1 for removing the patch digit.