Closed nanoant closed 8 years ago
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
).
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.
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.:
TM_JULIA
TextMate env variablejulia
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.
Patch releases don't make sense. They should be completely compatible.
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.
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.
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.
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.
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.
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.
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.
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"?
FYI: Keep Both keeps the old one in the original location and places new one adding -copy
suffix.
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.
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.
@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.
+1 to ditching the version number entirely.
@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.
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).
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.
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?
@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?
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.
@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).
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.
I think removing the patch digit is the right thing to do here.
+1 for removing the patch digit.
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:
Julia.app
julia
command. This matters me a lot, since TextMateJulia.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:
Julia.app
, so we can simply assume that usuallyjulia
command will be in/Applications/Julia.app/Contents/MacOS/julia
Finally there should be indeed a popup asking to install
/usr/local/bin/julia
symlink pointing insideJulia.app
when running the application. Something like: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.