How to update Julia?

How to update Julia?? :exploding_head:

1 Like

You can use juliaup, jill or (my personal favorite)
The manual way is to download the new version from the website and update your PATH / symlink, but it’s more cumbersome


There’s also asdf, my personal favourite, if only because it can handle much more than just Julia (it’s better than pyenv for updating python for instance).


Or you simply install julia in the same location as the previous version. This is simple and requires noch changes to path settings.
At least when you are going from 1.6.5 to 1.6.6 this seems to be a reasonable approach to me.


For me, the main advantage of using asdf instead of going the manual way is how easy it is to manage multiple versions of Julia. No need to handle paths by hand, a simple command pins the version of Julia I want for a certain folder and its subfolders.

1 Like

This can be done also when updating from, say, 1.7.x to 1.8.x.
Not to manually reinstall all the packages, , after installing, just create the v1.8 folder in the folder .julia/environments/ and copy the Project.toml file from the v1.7 to the v1.8 folder.
Then in a session of the new julia version run:

] instantiate

See FAQ.


I am aware. One reason not to do so is the fact that you may want to retain multiple minor versions (not sure if minor is the right term for the X in for 1.X.1)

I use Linux. When I want to install a (new) version of Julia, I download the tarball from the official website and untar it in ~/bin. This creates a directory such as julia-1.7.2.

Then, I link to the julia executable: cd ~/bin && ln -s julia-1.7.2/bin/julia. Since ~/bin is my $PATH, I can run julia just by typing julia in any shell. VS Code etc will also find it.

If I want to run a different version of julia, I just update the link or create a new one, for example with ln -s julia164 julia-1.6.4/bin/julia.

1 Like

That’s exactly what I do… with an additional step of renaming previous julia versions. So now I have symlinks julia12, julia13, julia14 all pointing to different versions. Sometimes its useful to run some code on an older versino of Julia.

1 Like

Why not using Much easier. And it uses the nearest download mirror.

jill install 1.8 --unstable # install the latest beta or rc version
jill switch 1.7 # make 1.7 the active version
jill switch 1.8 # make 1.8 the active version

You can also switch between different minor versions if you have them installed.

1 Like

This is exactly what does with many options to configure these paths.

Why I would bother with a Python package for something that takes less than a minute done by hand in Bash?

1 Like

One reason I use jill is that I have a start script for Julia that might load a system image, but with jill I can also let it use different julia versions per project… Sometimes very useful.

1 Like

Seems an interesting use case, and maybe make the package worth, in my case I do think the basic manual installation is enough.

Possibly because a minute is too long compared to writing jill install 1.8.0-rc1 :slight_smile:

I would have to figure out how to successfully install and configure Python, a task I have never accomplished. (Admittedly I have not tried very hard).

FWIW I have enjoyed using Scoop on Windows to install Julia. A simple scoop update Julia gets me the latest version. (But doesn’t handle multiple versions well so if that is needed this solution is suboptimal and I would recommend other techniques).

I… don’t understand the objection. With asdf you can install as many versions of Julia as you want, with different patch, minor or even major version numbers (as well as betas and release candidates. You can even manage the nightly with it!), and you can make your projects use any of your installed versions. So having a project run on 1.5.2, another on 1.6.5 and another on 1.8.0-rc1 is perfectly feasible and will work perfectly fine, and you don’t need to create softlinks by hand or to write a batch file for that.

And the best part is that asdf will work with other languages than Julia, so if you work with multiple languages you can all manage them with a single tool.

I have no objection at all.
I don’t know asdf, but I am sure it works great.
gdalle, mentioned some great alternatives above too.
My approach simply worked long before these existed and it is sufficient for me.

On Windows I would not use because Python is not pre-installed, there are other options for Windows. On Linux normally Python is pre-installed and automatically updated anyways.