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