Julia v1.4.0 has been released

Announcements
1

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.

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 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), and Cirrus (with CirrusCI.jl). As always, let us know in the issue tracker if you run into any issues.

Enjoy!

96 Likes
2

Excellent! Congratulations for this amazing work.

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

1 Like
3

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

7 Likes
4

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

1 Like
5

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.
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…

6

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!
  2. GitHub - JuliaCI/NanosoldierReports: A repository for human-readable reports generated by the Nanosoldier.jl CI system.
  3. GitHub - JuliaCI/Nanosoldier.jl: A package for running JuliaCI services on MIT's Nanosoldier cluster
  4. GitHub - JuliaCI/PkgEval.jl: Keeping tabs on the julia ecosystem
7 Likes
7

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.

6 Likes
8

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

6 Likes
9

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
1 Like
10

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.

2 Likes
11

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

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

2 Likes
12

This might be a case for the developers applying monotonic bounds in RetroCap. Going from 0.10 back to 0.2 is quite a difference, it would probably be more helpful to receive a Pkg incompatibility error.

3 Likes
13

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

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, where alea54 was the first to report issue on AMD Phenom

14

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:

Edit:

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

15

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?
2 Likes
16

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:

(@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:

(@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:
`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:
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), but not sure where to begin, or if others even want this.

5 Likes
17

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.

3 Likes
18

@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?

19

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.

3 Likes
20

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.

18 Likes