# Julia 0.6.0-rc3 now available

**URL:** <https://discourse.julialang.org/t/julia-0-6-0-rc3-now-available/4166>\
**Category:** Announcements\
**Tags:** announcement, release\
**Created:** [June 8, 2017, 9:17pm UTC](https://discourse.julialang.org/t/julia-0-6-0-rc3-now-available/4166 "2017-06-08T21:17:07Z")\
**Posts on this page:** 11\
**Page:** 1

<div class="post-metadata">

**Author:** ![tkelman](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tkelman/32/692_2.png) [@tkelman](https://discourse.julialang.org/u/tkelman)\
**Post date:** [June 8, 2017, 9:17pm UTC](https://discourse.julialang.org/t/julia-0-6-0-rc3-now-available/4166/1 "2017-06-08T21:17:07Z")

</div>

Hello all! We’ve just tagged the third release candidate for 0.6.0, and binaries are available from the usual [place](http://julialang.org/downloads/). See [this commit log](https://github.com/JuliaLang/julia/compare/v0.6.0-rc2...v0.6.0-rc3) for the list of bugs fixed since rc2. Please test your packages and other code, and report any regressions to either the [issue tracker](https://github.com/JuliaLang/julia/issues) or on discourse.

You can use “0.6” on Travis, or “0.6-latest” on Appveyor, and it will use the most recently tagged RC, or the final release once available. With any luck this might be the last RC, there will be a few more small bugfixes backported to release-0.6 but none of the open bugs I’m aware of seem large enough to be release-blocking.

-Tony

---

<div class="post-metadata">

**Author:** ![gopal2017](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/gopal2017/32/31747_2.png) [@gopal2017](https://discourse.julialang.org/u/gopal2017)\
**Post date:** [June 9, 2017, 7:35am UTC](https://discourse.julialang.org/t/julia-0-6-0-rc3-now-available/4166/2 "2017-06-09T07:35:02Z")

</div>

Hi,  
I faced tremendous problem for version. PyCall 64 bit, PYODBC AND  
JULIA IPOPT solver is not compatible with Julia Version 0.5.0 but  
compatible with 0.5.2. Julia is open source. JuMP is open source solver.  
Please let me know the reason for version. Can we change version from 0.5.2  
to 0.6.0? Can we run PyCall, pyodbc and Ipopt solver for 64 bit? Can we  
expect to have any datatype conversion issue?  
Thanks,

---

<div class="post-metadata">

**Author:** ![anon61610682](https://avatars.discourse-cdn.com/v4/letter/a/ad7895/32.png) [@anon61610682](https://discourse.julialang.org/u/anon61610682)\
**Post date:** [June 9, 2017, 7:52am UTC](https://discourse.julialang.org/t/julia-0-6-0-rc3-now-available/4166/3 "2017-06-09T07:52:29Z")

</div>

Hey,

You are asking whether some packages will be still usable in the new release. This is the problem of the package authors mostly, not the language committee. Please check the build logs of the corresponding packages to see if they are preparing for the new release:

- PyCall: [Travis CI - Test and Deploy Your Code with Confidence](https://travis-ci.org/JuliaPy/PyCall.jl)
- Ipopt: [Travis CI - Test and Deploy Your Code with Confidence](https://travis-ci.org/JuliaOpt/Ipopt.jl)

Both of them are testing against `Julia 0.5` and `Julia 0.7` (nightly stands for `0.7` if you check the logs). So, the package authors should be testing the code against `0.6` explicitly, and report their build status.

---

<div class="post-metadata">

**Author:** ![davidanthoff](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/davidanthoff/32/223493_2.png) [@davidanthoff](https://discourse.julialang.org/u/davidanthoff)\
**Post date:** [June 12, 2017, 5:48pm UTC](https://discourse.julialang.org/t/julia-0-6-0-rc3-now-available/4166/4 "2017-06-12T17:48:15Z")

</div>

What is the current thinking about next steps for the 0.6 release? Is there a chance we will have a release before juliacon? I think that would be great.

Also, any plans for another RC? My understanding is that folks think that [https://github.com/JuliaLang/julia/pull/22282](https://github.com/JuliaLang/julia/pull/22282) fixed [https://github.com/JuliaStats/Feather.jl/issues/46](https://github.com/JuliaStats/Feather.jl/issues/46). It would be great if there were Windows binaries that allowed me to test and confirm that and also to make sure #22282 didn’t introduce any regressions, it seems like a PR that touches a very core part of julia, so maybe a good idea to have a RC that includes it?

CC @tkelman, @jameson and @quinnj.

---

<div class="post-metadata">

**Author:** ![ExpandingMan](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/expandingman/32/866_2.png) [@ExpandingMan](https://discourse.julialang.org/u/ExpandingMan)\
**Post date:** [June 12, 2017, 6:10pm UTC](https://discourse.julialang.org/t/julia-0-6-0-rc3-now-available/4166/5 "2017-06-12T18:10:45Z")

</div>

22282 is definitely going to be part of 0.6 I hope?

---

<div class="post-metadata">

**Author:** ![ChrisRackauckas](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/chrisrackauckas/32/77_2.png) [@ChrisRackauckas](https://discourse.julialang.org/u/ChrisRackauckas)\
**Post date:** [June 12, 2017, 6:23pm UTC](https://discourse.julialang.org/t/julia-0-6-0-rc3-now-available/4166/6 "2017-06-12T18:23:25Z")

</div>

> [@davidanthoff](#):
>
> What is the current thinking about next steps for the 0.6 release? Is there a chance we will have a release before juliacon? I think that would be great.

I’d be scared of a JuliaCon v0.6 release without a fix for:

> <https://github.com/JuliaLang/julia/issues/21969>
>
> Example:
> 
> \`\`\`julia
> using DifferentialEquations
> 
> INFO: Recompiling stale cac…he file C:\\Users\\Chris\\.julia\\lib\\v0.6\\Combinatorics.ji for module Combinatorics.
> WARNING: The call to compilecache failed to create a usable precompiled cache file for module Combinatorics. Got:
> WARNING: Module Iterators uuid did not match cache file.
> \`\`\`
> 
> Also posted at https://github.com/JunoLab/Atom.jl/issues/86. For some reason, the REPL works but Juno fails often, and if I hit it with a few \`using\`s in the REPL (for some reason, a few), and then close and re-open Juno, it's finally able to find the right precompilation caches. I'm not entirely sure if this is Juno or Base.

It looked like rc3 had a fix, but that commit didn’t seem to be the true fix. For reference, it makes precompilation happen every time a dependency of Iterators.jl is imported, and if Iterators.jl (and maybe Combinatorics.jl?) is not imported first, precompilation will fail. So this both makes precompilation happen every time, and fail without doing the workaround.

This ends up being an issue because many packages (DiffEq, Roots.jl, Bio.jl, etc.) are downstream of Iterators, and so all of them don’t work without knowing “the trick” to `using Iterators, Combinatorics` beforehand, which is really not friendly. I put in some PRs to get everything related to DiffEq no longer dependent on Iterators, but there’s still a lot that misses (even heavy-hitters like Bio.jl, GeometryTypes.jl, GLVisualize.jl, Gadfly.jl, etc.). It’s an evil nasty bug that wouldn’t show up in Base tests either, and I still have no idea why it happens. But at least we can “get rid of it” by updating packages to not use Iterators.jl.

---

<div class="post-metadata">

**Author:** ![davidanthoff](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/davidanthoff/32/223493_2.png) [@davidanthoff](https://discourse.julialang.org/u/davidanthoff)\
**Post date:** [June 12, 2017, 6:56pm UTC](https://discourse.julialang.org/t/julia-0-6-0-rc3-now-available/4166/7 "2017-06-12T18:56:58Z")

</div>

The bug that worries me is [https://github.com/JuliaLang/julia/issues/17994](https://github.com/JuliaLang/julia/issues/17994), I really would hope that this gets fixed before a release, it just deleted real work I had done a couple of days ago again…

---

<div class="post-metadata">

**Author:** ![iamed2](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/iamed2/32/215082_2.png) [@iamed2](https://discourse.julialang.org/u/iamed2)\
**Post date:** [June 12, 2017, 7:24pm UTC](https://discourse.julialang.org/t/julia-0-6-0-rc3-now-available/4166/8 "2017-06-12T19:24:13Z")

</div>

This is a concerning development. Developers removing Iterators.jl dependencies in favour of copied code is a major fragmentation issue. I definitely don’t blame them given the problem they need to solve. One possible solution to the emergent issue (not the underlying bug): [https://github.com/JuliaCollections/Iterators.jl/issues/104](https://github.com/JuliaCollections/Iterators.jl/issues/104)

---

<div class="post-metadata">

**Author:** ![MikeInnes](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mikeinnes/32/3656_2.png) [@MikeInnes](https://discourse.julialang.org/u/MikeInnes)\
**Post date:** [June 13, 2017, 2:39pm UTC](https://discourse.julialang.org/t/julia-0-6-0-rc3-now-available/4166/9 "2017-06-13T14:39:37Z")

</div>

Julia now has many common iterators in `Base.Iterators`, and many of them are Jeff-optimised (so faster than the simple versions in Iterators.jl). I was able to replace my usage with that, rather than duplicating code.

---

<div class="post-metadata">

**Author:** ![ChrisRackauckas](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/chrisrackauckas/32/77_2.png) [@ChrisRackauckas](https://discourse.julialang.org/u/ChrisRackauckas)\
**Post date:** [June 13, 2017, 2:46pm UTC](https://discourse.julialang.org/t/julia-0-6-0-rc3-now-available/4166/10 "2017-06-13T14:46:33Z")

</div>

> [@MikeInnes](#):
>
> I was able to replace my usage with that, rather than duplicating code.

`chain` seems to be the main part that is missing.

---

<div class="post-metadata">

**Author:** ![ExpandingMan](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/expandingman/32/866_2.png) [@ExpandingMan](https://discourse.julialang.org/u/ExpandingMan)\
**Post date:** [June 13, 2017, 5:48pm UTC](https://discourse.julialang.org/t/julia-0-6-0-rc3-now-available/4166/11 "2017-06-13T17:48:10Z")

</div>

I’m getting sporadic segfaults which almost definitely seem to be coming from Julia itself, and, though not necessarily a brand new problem, seem to be much exacerbated in 0.6-rc3, see here.