Julia 1.3.0-alpha is now available

The Julia developers are pleased to announce that, as those of you at JuliaCon may already know, Julia v1.3.0-alpha has been released. Binaries are available for Linux (i686, x86-64, ARMv7, AArch64), macOS, Windows (32-, 64-bit), and FreeBSD (x86-64) on https://julialang.org/downloads.

As an alpha version, this should not be considered production ready, nor should it be considered a release candidate. We’ve made an alpha available early for 1.3 because it introduces exciting new multithreading advancements, and we’d love for the community to get a taste of what’s to come and to start thinking about thread safety in packages. You can hear more about the new thread based parallelism in Jeff and Jameson’s JuliaCon talk, available on YouTube. Also check out the NEWS file file for v1.3.0-alpha for a complete list of changes.

“What, 1.3? Where’s 1.2?” you may be asking. Don’t worry, that’s still in the works! 1.2.0 should be released fairly soon. Despite the excitement over 1.3, we haven’t forgotten about 1.2.

Note that 1.3 is now available by name on Travis, AppVeyor (using Appveyor.jl) and Cirrus CI (using CirrusCI.jl). We encourage folks to give it a try and let us know in the issue tracker if you run into any issues.

Happy coding!


Super excited about threading! There is no release-1.3 branch yet.

Correct, we haven’t yet branched for 1.3; we typically do that when we’re ready for release candidates.

Suppose I wanted to multi-thread a package I’m working on over the next few weeks. Would you switch to 1.3 now or remain on <= 1.2?

In other words - how much breaking change to the Threads package is there? Will I have to rewrite a lot? The NEWS seems to suggest that there are mostly improvements but not necessarily changes to e.g @threads.

From what I understand @threads won’t change, but you won’t have the new @spawn interface in 1.2.

1 Like

I neglected to mention the blog post on multithreading! I recommend giving that a read as well.


Would there be preference of @spawn over @threads?

One is implemented in terms of the other so no.