Hello all! We’ve just tagged the third release candidate for 0.6.0, and binaries are available from the usual place. See this commit log for the list of bugs fixed since rc2. Please test your packages and other code, and report any regressions to either the issue tracker 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.
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,
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:
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.
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 fixed 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?
I’d be scared of a JuliaCon v0.6 release without a fix for:
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.
The bug that worries me is 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…
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
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.
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.