After 25 days in alpha, we’re pleased to announce that Julia 0.7 is now in beta. As such, v0.7.0-beta binaries are now available for all of your favorite platforms: Linux (i686, x86-64), Windows (32-, 64-bit), FreeBSD (x86-64), and macOS. Get them while they’re hot at Download Julia in the “upcoming release” section. You can view Julia 0.7 release notes here (includes all 0.7 changes) and see the commits included since 0.7-alpha here.
As with 0.7-alpha, 0.7-beta is not to be considered production-ready; it’s intended to give developers a chance to get a feel for what a 0.7 release will look like, start getting their code up to date, and test for issues. Most users should continue to use the latest release, 0.6.3, until 0.7.0 is fully released. Please report any issues you may come across at Issues · JuliaLang/julia · GitHub.
That said, now is a good time to get your packages ready for 0.7. You can specify 0.7 in your Travis matrix, which will use the beta, in addition to nightly, which will use the master branch built nightly. While similar, 0.7 and nightly should generally not be considered equivalent; it’s best to test on both.
We’re certainly excited about 0.7 and we hope you’ll give the beta a try and start readying the world for 0.7. Happy coding!
Some of those are legitimate bugs but fairly obscure ones that one is not too likely to run into; others are feature requests or speculative design issues. Are you running into a particular one that’s causing problems? I’m sure some of the bug issues will get closed between now and 1.0 but improving compile times is the top priority for compiler work at the moment.
Item 1 was already fixed but apparently it broke a CI scripts and I didn’t get feedback on what needed to be fixed there in time for the beta, so I reverted the change. If you want to emulate the final behavior just do this in your shell startup scripts:
export JULIA_LOAD_PATH="@v#.#:@stdlib"
Or if you want to keep the current behavior in the future, you can do this instead:
export JULIA_LOAD_PATH="@@:"
Item 2 should not break registered packages once the package manager itself is fixed. Items 3 & 4 are technically breaking but… really? These are pretty obscure changes. Item 5 is not breaking. So realistically two changes to worry about.
I note that Windows Defender complains about the beta executable (not being ‘trustworthy’). I do not think this was the case with alpha. Maybe the beta exe (64bit) was not properly signed.
What about compiler performance? Is it expected to be fixed for the release? Right now loading precompiled packages seem to be 2-3x slower, or is it just me? Actual runtime performance is better, but the latency of loading code is making things like running tests much slower.
I’m asking because I’m about to start a pretty big new project, and I’d rather use 0.7 so I don’t have to change when 1.0 shows up. Right now it is just a scaffold with almost no code, so I have it both in v0.6 and v0.7 to compare. Interactive sessions start 2x faster, tests run 2.5x faster in v0.6, adding distributed workers with addprocs is 3x faster. All these things add up While all my benchmarks show improvements in v0.7, actual use with iterative development is a lot slower.
Please tell me it is going to be fixed for the release…
I faced a similar decision some time ago. I decided 0.7 had so much new stuff it would not make sense to develop for 0.6 anymore. At some points I’ve almost regretted it, because 0.7 has been a bit of a rocky ride, but now 0.7 is much tighter, and I’m really glad of my choice. I’ve not suffered so much with precompilation times. I guess it depends on the size of your project. In any case, if I were to start a project now, I would no doubt aim for 0.7, but that may be just me.
Not to disregard the importance of compiler performance, but developing with Revise.jl typically means you have to restart less. The only issue is changing the layout of structs which AFAIU requires a restart, but is something that you do quite often when developing.
I often rely on ~5-10 packages, so I find it impossible to do stuff in 0.7. But I guess it’s still early on, so I’m basically waiting for more passing green lights for the 0.7 versions.
Given the dependencies between packages, perhaps a priority list for getting packages working with 0.7 would be good, so people with time to try to make PRs would know where to work most productively? Starting with “important” packages that have relatively few dependencies seems a logical place to start. I’d be interested in someone pointing me to relatively simple and useful things to do. Is there a list of which packages are working with 0.7?
While all my benchmarks show improvements in v0.7, actual use with iterative development is a lot slower.