# Julia v1.4.0 has been released

**URL:** <https://discourse.julialang.org/t/julia-v1-4-0-has-been-released/36324>\
**Category:** Announcements\
**Created:** [March 22, 2020, 12:45am UTC](https://discourse.julialang.org/t/julia-v1-4-0-has-been-released/36324 "2020-03-22T00:45:44Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![ararslan](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ararslan/32/3825_2.png) [@ararslan](https://discourse.julialang.org/u/ararslan)\
**Post date:** [March 22, 2020, 12:45am UTC](https://discourse.julialang.org/t/julia-v1-4-0-has-been-released/36324/1 "2020-03-22T00:45:44Z")

</div>

The Julia developers are pleased to annouce the release of Julia v1.4.0, the fourth minor release in the 1.x series. Binaries are available for all of your favorite platforms (Linux, macOS, Windows, and FreeBSD) at [Download Julia](https://julialang.org/downloads).

As a minor release, v1.4.0 contains no breaking changes, only new features, performance improvements, and marginal, undisruptive changes in behavior. The best reference for the changes in 1.4 is the [NEWS file](https://github.com/JuliaLang/julia/tree/v1.4.0/NEWS.md) for 1.4.0.

Note that 1.4, like 1.3, 1.2, and 1.1 before it, does not have long term support. As of this release, 1.3 has been effectively superseded by 1.4, which means there will not likely be any further 1.3.x releases. Julia 1.0 is still currently the only long term support version.

We encourage everyone to give it a try. Packages can test with 1.4.0 on CI by specifying `1.4` on Travis, AppVeyor (with [Appveyor.jl](https://github.com/JuliaCI/Appveyor.jl)), and Cirrus (with [CirrusCI.jl](https://github.com/ararslan/CirrusCI.jl)). As always, let us know in the [issue tracker](https://github.com/JuliaLang/julia/issues) if you run into any issues.

Enjoy!

---

<div class="post-metadata">

**Author:** ![Ronis\_BR](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ronis_br/32/50999_2.png) [@Ronis\_BR](https://discourse.julialang.org/u/Ronis_BR)\
**Post date:** [March 22, 2020, 1:15am UTC](https://discourse.julialang.org/t/julia-v1-4-0-has-been-released/36324/2 "2020-03-22T01:15:23Z")

</div>

Excellent! Congratulations for this amazing work.

> [@ararslan](#):
>
> We encourage everyone to give it a try. Packages can test with 1.4.0 on CI by specifying `1.3` on Travis,

Is it a typo or we really need to specify `1.3`?

---

<div class="post-metadata">

**Author:** ![ararslan](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ararslan/32/3825_2.png) [@ararslan](https://discourse.julialang.org/u/ararslan)\
**Post date:** [March 22, 2020, 1:17am UTC](https://discourse.julialang.org/t/julia-v1-4-0-has-been-released/36324/3 "2020-03-22T01:17:06Z")

</div>

> [@Ronis\_BR](#):
>
> Is it a typo or we really need to specify `1.3` ?

Whoops, sorry about that. That was indeed a typo. It’s 1.4 to get 1.4. 🙂

---

<div class="post-metadata">

**Author:** ![bashonubuntu](https://avatars.discourse-cdn.com/v4/letter/b/f19dbf/32.png) [@bashonubuntu](https://discourse.julialang.org/u/bashonubuntu)\
**Post date:** [March 22, 2020, 2:14am UTC](https://discourse.julialang.org/t/julia-v1-4-0-has-been-released/36324/4 "2020-03-22T02:14:26Z")

</div>

Thanks for this piece of very positive news in a time of grave uncertainty and turmoil 🙂

---

<div class="post-metadata">

**Author:** ![Albert\_Zevelev](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/albert_zevelev/32/11844_2.png) [@Albert\_Zevelev](https://discourse.julialang.org/u/Albert_Zevelev)\
**Post date:** [March 22, 2020, 5:28am UTC](https://discourse.julialang.org/t/julia-v1-4-0-has-been-released/36324/5 "2020-03-22T05:28:25Z")

</div>

Thanks, I’m excited to test drive Julia v1.4!

The first thing I did in Julia v1.4 was add the package [MLJ.jl](https://github.com/alan-turing-institute/MLJ.jl/releases).  
Julia installed `MLJ v0.2.3` instead of the latest version `MLJ v0.10.1`.

Is there some kind of testing that can be done before a new version of Julia is released to check that, say, the top 20 Julia packages (by github stars) work? And the maintainers can be notified pre-release if there is an issue?

Update: I ran `rm -rf ~/.julia` , opened Julia & `Pkg.add("MLJ")` now installed the latest.  
That said, it could be nice to test the most frequently used Julia packages before a release…

---

<div class="post-metadata">

**Author:** ![dilumaluthge](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/dilumaluthge/32/29283_2.png) [@dilumaluthge](https://discourse.julialang.org/u/dilumaluthge)\
**Post date:** [March 22, 2020, 6:26am UTC](https://discourse.julialang.org/t/julia-v1-4-0-has-been-released/36324/6 "2020-03-22T06:26:33Z")

</div>

> [@Albert\_Zevelev](#):
>
> Is there some kind of testing that can be done before a new version of Julia is released to check that, say, the top 20 Julia packages (by github stars) work? And the maintainers can be notified pre-release if there is an issue?

> [@Albert\_Zevelev](#):
>
> That said, it could be nice to test the most frequently used Julia packages before a release…

We already do exactly that. We test all registered Julia packages (registered in the General registry) prior to making a Julia release. We also do this every day on the latest Julia master. See:

1. [ANN: Nanosoldier package evaluation -- with badges!](https://discourse.julialang.org/t/ann-nanosoldier-package-evaluation-with-badges/33339)
2. [GitHub - JuliaCI/NanosoldierReports: A repository for human-readable reports generated by the Nanosoldier.jl CI system.](https://github.com/JuliaCI/NanosoldierReports)
3. [GitHub - JuliaCI/Nanosoldier.jl: A package for running JuliaCI services on MIT's Nanosoldier cluster](https://github.com/JuliaCI/Nanosoldier.jl)
4. [GitHub - JuliaCI/PkgEval.jl: Keeping tabs on the julia ecosystem](https://github.com/JuliaComputing/NewPkgEval.jl)

---

<div class="post-metadata">

**Author:** ![dilumaluthge](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/dilumaluthge/32/29283_2.png) [@dilumaluthge](https://discourse.julialang.org/u/dilumaluthge)\
**Post date:** [March 22, 2020, 6:29am UTC](https://discourse.julialang.org/t/julia-v1-4-0-has-been-released/36324/7 "2020-03-22T06:29:14Z")

</div>

The problem you were experiencing was due to some issue with your local environment, as evidenced by the fact that it was fixed by `rm -rf ~/.julia`.

In general, when people experience an issue with packages, my first advice is always to `rm -rf ~/.julia`. I know that it seems extreme, but it really does fix the vast majority of problems.

---

<div class="post-metadata">

**Author:** ![Tamas\_Papp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tamas_papp/32/25949_2.png) [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)\
**Post date:** [March 22, 2020, 6:58am UTC](https://discourse.julialang.org/t/julia-v1-4-0-has-been-released/36324/8 "2020-03-22T06:58:56Z")

</div>

> [@dilumaluthge](#):
>
> my first advice is always to `rm -rf ~/.julia` . I know that it seems extreme

Note that this could lead to work lost in packages checked out for development. May not be an issue for new users though.

I think that the manual should contain advice about this, cf

> <https://github.com/JuliaLang/Pkg.jl/issues/1683>
>
> Occasionally parts of the depot become corrupted (because of interrupted downloa…ds/processes, bugs in Pkg, etc). While this is not part of the normal workflow, it would be great if the manual could have a section on how to recover from these situations, that could be linked eg on Discourse.
> 
> Eg 
> 
> 1. establish the depot path (examples below assume the default)
> 2. remove \`~/.julia/packages\`
> 3. remove the global manifest,
> 4. restart julia and do a \`pkg\> resolve\`?

---

<div class="post-metadata">

**Author:** ![dilumaluthge](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/dilumaluthge/32/29283_2.png) [@dilumaluthge](https://discourse.julialang.org/u/dilumaluthge)\
**Post date:** [March 22, 2020, 7:09am UTC](https://discourse.julialang.org/t/julia-v1-4-0-has-been-released/36324/9 "2020-03-22T07:09:29Z")

</div>

> [@Tamas\_Papp](#):
>
> Note that this could lead to work lost in packages checked out for development.

That’s a good point. I suppose my advice should actually be:

1. Commit all changes in any packages that you have checked out for development
2. Push all changes to a remote (GitHub, GitLab, etc.)
3. `rm -rf ~/.julia`

And of course, if you don’t have any packages checked out for development, then you simply do:

1. `rm -rf ~/.julia`

---

<div class="post-metadata">

**Author:** ![GunnarFarneback](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/gunnarfarneback/32/1827_2.png) [@GunnarFarneback](https://discourse.julialang.org/u/GunnarFarneback)\
**Post date:** [March 22, 2020, 8:52am UTC](https://discourse.julialang.org/t/julia-v1-4-0-has-been-released/36324/10 "2020-03-22T08:52:11Z")

</div>

It seems overly drastic to start by removing lots of files and REPL history and what not. My advice if you suspect problem with your depot would be to create an empty directory somewhere and point `JULIA_DEPOT_PATH` to it. If that works you can start to think about removing stuff in `~/.julia`. If it doesn’t the problem is likely elsewhere and no amount of destruction in your normal depot will help you.

---

<div class="post-metadata">

**Author:** ![jaakkor2](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jaakkor2/32/2540_2.png) [@jaakkor2](https://discourse.julialang.org/u/jaakkor2)\
**Post date:** [March 22, 2020, 8:53am UTC](https://discourse.julialang.org/t/julia-v1-4-0-has-been-released/36324/11 "2020-03-22T08:53:30Z")

</div>

Rather than removing `~/.julia`, I would suggest looking at the `[compat]` section of `Project.toml` of the two MJL versions

> <https://github.com/alan-turing-institute/MLJ.jl/blob/v0.2.3/Project.toml>

> <https://github.com/alan-turing-institute/MLJ.jl/blob/v0.10.1/Project.toml>

If I interpret correctly, if you had installed Distributions v0.23 a few days ago, then you would not fulfill `Distributions = "^0.21,^0.22"`, and the installer would fall back to MLJ v0.2.3.

MLJ v0.2.4 would not install since it depends on `MLJBase = "0.2.3"`, which maybe was hold back by `CSV = "0.5"` in [MLJBase.jl/Project.toml at v0.2.3 · JuliaAI/MLJBase.jl · GitHub](https://github.com/alan-turing-institute/MLJBase.jl/blob/v0.2.3/Project.toml)

---

<div class="post-metadata">

**Author:** ![tim.holy](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tim.holy/32/52_2.png) [@tim.holy](https://discourse.julialang.org/u/tim.holy)\
**Post date:** [March 22, 2020, 9:18am UTC](https://discourse.julialang.org/t/julia-v1-4-0-has-been-released/36324/12 "2020-03-22T09:18:06Z")

</div>

This might be a case for the developers applying monotonic bounds in [RetroCap](https://github.com/bcbi/RetroCap.jl). Going from 0.10 back to 0.2 is quite a difference, it would probably be more helpful to receive a Pkg incompatibility error.

---

<div class="post-metadata">

**Author:** ![jdad](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jdad/32/4739_2.png) [@jdad](https://discourse.julialang.org/u/jdad)\
**Post date:** [March 22, 2020, 9:49am UTC](https://discourse.julialang.org/t/julia-v1-4-0-has-been-released/36324/13 "2020-03-22T09:49:15Z")

</div>

Sorry to report a glitch on Linux 64 bits with (old) AMD processor (Turion II M640)

```julia
Invalid instruction at 0x7ff8b4a3f1d0: 0x66, 0x0f, 0x3a, 0x0f, 0xc0, 0x08, 0x0f, 0x83, 0xae, 0x04, 0x00, 0x00, 0x48, 0xc1, 0xe0

signal (4): Illegal instruction
in expression starting at none:0
_ZN4llvm13LexicalScopes23assignInstructionRangesERNS_15SmallVectorImplISt4pairIPKNS_12MachineInstrES5_EEERNS_8DenseMapIS
...
jl_module_run_initializer at /buildworker/worker/package_linux64/build/src/toplevel.c:74
_julia_init at /buildworker/worker/package_linux64/build/src/init.c:788
unknown function (ip: 0x401527)
__libc_start_main at /lib64/libc.so.6 (unknown line)
unknown function (ip: 0x4015d4)
Allocations: 2502 (Pool: 2493; Big: 9); GC: 0
Illegal instruction (core dumped)

```

More info on [https://github.com/JuliaLang/julia/issues/35215](https://github.com/JuliaLang/julia/issues/35215), where alea54 was the first to report issue on AMD Phenom

---

<div class="post-metadata">

**Author:** ![Gnimuc](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/gnimuc/32/2194_2.png) [@Gnimuc](https://discourse.julialang.org/u/Gnimuc)\
**Post date:** [March 22, 2020, 10:00am UTC](https://discourse.julialang.org/t/julia-v1-4-0-has-been-released/36324/14 "2020-03-22T10:00:52Z")

</div>

~~Just want to confirm, what LLVM binaries were being used when building those released Julia binaries? It looks like there’re compatibility issues on Windows and Linux:~~

~~- [Travis CI](https://travis-ci.org/github/JuliaInterop/Clang.jl?utm_medium=notification)
~~-~~ [https://github.com/JuliaBinaryWrappers/LLVM\_jll.jl/issues/3](https://github.com/JuliaBinaryWrappers/LLVM_jll.jl/issues/3)  
~~

### Edit:

I noticed the Julia version on Travis CI is still Julia-1.4rc2, this might cause the above issue. (fixed now)

---

<div class="post-metadata">

**Author:** ![DNF](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/dnf/32/10191_2.png) [@DNF](https://discourse.julialang.org/u/DNF)\
**Post date:** [March 22, 2020, 11:50am UTC](https://discourse.julialang.org/t/julia-v1-4-0-has-been-released/36324/15 "2020-03-22T11:50:06Z")

</div>

What can I do to fix issues while keeping most of the useful stuff, like my repl history?

- For example, should I just back up my `repl_history.jl` file, and copy it back over after `rm -rf ~/.julia`?
- What else should I try to keep? Any suggestions?
- How do I automatically reinstall all packages after deleting them?

---

<div class="post-metadata">

**Author:** ![Albert\_Zevelev](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/albert_zevelev/32/11844_2.png) [@Albert\_Zevelev](https://discourse.julialang.org/u/Albert_Zevelev)\
**Post date:** [March 22, 2020, 6:50pm UTC](https://discourse.julialang.org/t/julia-v1-4-0-has-been-released/36324/16 "2020-03-22T18:50:48Z")

</div>

To build on what people here are saying:  
I installed `Julia 1.4.0`, then `rm -rf ~/.julia`.  
Next installed `MLJ.jl`, followed by `Distributions.jl`.  
Here is the message I got:

```nohighlight
(@v1.4) pkg> add Distributions
  Resolving package versions...
   Updating `~/.julia/environments/v1.4/Project.toml`
  [31c24e10] + Distributions v0.22.6
   Updating `~/.julia/environments/v1.4/Manifest.toml`
 [no changes]

```

Next when I check status:

```nohighlight
(@v1.4) pkg> status
Status `~/.julia/environments/v1.4/Project.toml`
  [31c24e10] Distributions v0.22.6
  [add582a8] MLJ v0.10.1

```

It would be great if

1. Julia warns me when it adds a package which is not the latest or some kind of Pkg incompatability error as @tim.holy mentions:

```nohighlight
`Note you have installed Distributions v0.22.6, not the latest 
Distributions v0.23.0 because it conflicts with MLJ v0.10.1.`  

```

1. Let `Pkg.status()` display two columns, the package I have & the latest version:

```nohighlight
Package Installed version	Latest version
Distributions v0.22.6 v0.23.0
MLJ v0.10.1 v0.10.1

```

I’d submit a PR to ([https://github.com/JuliaLang/Pkg.jl](https://github.com/JuliaLang/Pkg.jl)), but not sure where to begin, or if others even want this.

---

<div class="post-metadata">

**Author:** ![BVPs](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/bvps/32/2190_2.png) [@BVPs](https://discourse.julialang.org/u/BVPs)\
**Post date:** [March 22, 2020, 7:08pm UTC](https://discourse.julialang.org/t/julia-v1-4-0-has-been-released/36324/17 "2020-03-22T19:08:05Z")

</div>

Yes, I usually keep `~/.julia/logs/repl_history.jl` and the folder`~/.julia/config`, which I have some initialization file such as `startup.jl` before wiping out `~/.julia`. In fact, it’s safer to copy `~/.julia` to something like `~/.julia.bak` before wiping out `~/.julia`.  
As for reinstalling the packages, you might want to copy e.g., `~/.julia.bak/environments/v1.3` folder to `~/.julia/environments/v1.4` if you have a large number of packages. But usually, when the new version of Julia is released, I install various packages from scratch and try to install/add only really important packages for my projects. That way, I can cleanup and remove some unnecessary packages that I happened to try previously.

---

<div class="post-metadata">

**Author:** ![ablaom](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ablaom/32/4889_2.png) [@ablaom](https://discourse.julialang.org/u/ablaom)\
**Post date:** [March 22, 2020, 9:03pm UTC](https://discourse.julialang.org/t/julia-v1-4-0-has-been-released/36324/18 "2020-03-22T21:03:23Z")

</div>

@tim.holy I am not familiar with RetroCap and am confused about its use. Is the idea that a developer applies it to a local version of General.jl (somehow restricting its application to the repos owned by the developer) and then makes a PR to General?

---

<div class="post-metadata">

**Author:** ![tim.holy](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tim.holy/32/52_2.png) [@tim.holy](https://discourse.julialang.org/u/tim.holy)\
**Post date:** [March 22, 2020, 9:04pm UTC](https://discourse.julialang.org/t/julia-v1-4-0-has-been-released/36324/19 "2020-03-22T21:04:57Z")

</div>

Exactly. The PR will be manually reviewed, and shouldn’t be merged if it touches repos that the submitter doesn’t have significant developer stake in.

---

<div class="post-metadata">

**Author:** ![chakravala](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/chakravala/32/6832_2.png) [@chakravala](https://discourse.julialang.org/u/chakravala)\
**Post date:** [March 23, 2020, 2:27am UTC](https://discourse.julialang.org/t/julia-v1-4-0-has-been-released/36324/20 "2020-03-23T02:27:32Z")

</div>

Instead of `rm -rf ~/.jullia` it’s better to recommend `mv ~/.julia ~/.julia.bak`, which is safer. I’m just pointing this out because I don’t want people to accidentally delete their work.

[Next page](https://discourse.julialang.org/t/julia-v1-4-0-has-been-released/36324.md?page=2)