Julia 0.7.0-beta is now available

release

#1

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 https://julialang.org/downloads 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 https://github.com/JuliaLang/julia/issues.

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!


#3

Thanks a lot to the whole team for all your efforts !


#4

Are there still breaking changes being contemplated? The issue tracker seems to suggest that. What is the current plan for a feature freeze?


Julia 0.7.0-alpha is now available
#5

There should be minimal breaking changes after the beta. What issues are you referring to?


#6

I would like to ready the world for 0.7 but lots of subtyping regressions/bugs have not been fixed:


Will they get some attention or does one have to wait for v1.1?


#7

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.


#8


It is failing using the beta (it worked on 0.6).


#9

The issues on the 0.7 milestone.


#10

There are five items currently:

  1. Change the default load path not to include the current directory’s enclosing project.
  2. Don’t put @stdlib in the load path when testing or building packages.
  3. Make juxtaposition slightly lower precedence than unary operators.
  4. Give reshape with Val arguments a different API?
  5. Return basic statistical functionality to Base.

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.


#11

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.


#12

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 :frowning: 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…


#13

Compile time is being worked on and will continue to be worked on after the 1.0 release.


#14

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.


#15

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.


#16

I completely agree, for me the hardest part was/is the lack of packages available for 0.7.


#17

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.


#18

So do I, but I found that packages are very happy to accept PRs. Updating so that things run on v0.7 is mostly mechanical and easy to do.


#19

I figured someone would suggest that…
:no_mouth:


#20

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?


#21

A good strategy is just to fix packages you are using (checking that eg master is not fixed already, in which case just ask for a tagged release).

I find that many package maintainers have already started updating things for v0.7. The packages which are still WIP tend to be more complex ones.