0.6 release timeline

Fortunately, we don’t have any major infrastructure upgrades like we did in the 0.5 release (LLVM, libgit2 and SSL stuff – what a nightmare that was)

For the future, I wonder if we should have a policy that encourages us to schedule changes in LLVM and other core dependencies for a time when there’s the maximum chance for having them be testable with PkgEval (in addition to Julia’s own tests), so that we get the best picture possible of the consequences and are not left scrambling trying to fix unanticipated problems. I’m not quite sure what the best timing would be, but I suspect that we could allow it as long as we’re near the peak in terms of the number of packages that are working with master (likely, early in the development of the next release).

Stated differently, that means waiting for the next release cycle for certain types of changes, depending on the timing with which they are submitted. Obviously that strategy has its negatives, but as Julia settles into a pattern of less-frenetic change that might be viable?

1 Like

Yes, that does seem to be the lesson. We upgraded LLVM from 3.7.1 to 3.9.1 early on in the 0.6 cycle. That was a minor upgrade – nothing like the crazy leap from 3.3 to 3.7.1 we made in 0.5 – but it was good to get it done early so that there was as much time as possible to upstream inevitable patches to LLVM and find bugs.

0.6 alpha has been tagged and binaries are available. You can now use “0.6” on Travis, or “0.6-latest” on Appveyor, and it will use the most recently tagged pre-release or release candidate. We haven’t branched release-0.6 off of master yet though and probably won’t until we go through a beta and a few release candidates, whenever there are enough blocked feature PR’s to make it worth branching. So for now the nightlies will be more up-to-date with bug fixes but should be functionally equivalent. Please report anything that regresses between this alpha and nightlies.

https://s3.amazonaws.com/julialang/bin/checksums/julia-0.6.0-pre.alpha.sha256
https://s3.amazonaws.com/julialang/bin/winnt/x86/0.6/julia-0.6.0-pre.alpha-win32.exe
https://s3.amazonaws.com/julialang/bin/winnt/x64/0.6/julia-0.6.0-pre.alpha-win64.exe
https://s3.amazonaws.com/julialang/bin/osx/x64/0.6/julia-0.6.0-pre.alpha-osx10.7+.dmg
https://s3.amazonaws.com/julialang/bin/linux/x86/0.6/julia-0.6.0-pre.alpha-linux-i686.tar.gz
https://s3.amazonaws.com/julialang/bin/linux/x64/0.6/julia-0.6.0-pre.alpha-linux-x86_64.tar.gz
https://s3.amazonaws.com/julialang/bin/linux/arm/0.6/julia-0.6.0-pre.alpha-linux-arm.tar.gz
https://s3.amazonaws.com/julialang/bin/linux/ppc64le/0.6/julia-0.6.0-pre.alpha-linux-ppc64le.tar.gz

24 Likes

Hello,

just for my understanding: What is the process to get issues into the 0.6 milestone on github?
I recently (like others working in a proxied/firewalled environment) got entangled into the https://github.com/JuliaLang/julia/issues/20948 and it looks like this has been solved in the current 0.6 linux+windows build, but it never showed up as 0.6 issue. Which it is.

Do usability issues only qualify for 0.6.x?

btw: Documentation is still missing on this (how to set etc.)

Master has not branched yet so AFAIU everything that gets currently merged will be available for 0.6.

I appreciate the continued effort by the release team on polishing up 0.6! It seems to be very close now.

Is there a revised timeline for the releases of 0.6 and 1.0? I guess that 1.0 by JuliaCon this year is no longer realistic.

There are zero (0) issues with the 0.6 milestone left. Does this mean, that 0.6 beta will be released soon?

2 Likes

afaiu the issue counter reached 0 only some hours ago. I’d guess there is some heavy testing in the background right now. But yeah, soon!

2 Likes

Julia 0.6 is already in the beta phase; the current version is 0.6.0-pre.beta. Next will be release candidates, which I imagine (with no data to support this–just a guess) that a first RC will be released within the next week or two.

I’m shure that in the next few days we will see the so awaited 0.6 RC

If I want to test, which tag should I compile? Or should I still go with master?

Is the current plan for Julia 0.6 to become Julia 1.0? Or are there plans for major changes between the two?

This got tagged earlier today–
https://github.com/JuliaLang/julia/tree/release-0.6

2 Likes

Please note that it’s a branch, not a tag (that should be named v0.6.0). This subtle difference means that julia 0.6 is not completely finished, but hopefully very close.

2 Likes

I just wanted to test some behavior in something more recent than pre-beta, but I guess I will just stick to the latest on that branch.

The plan that I understood was that there are changes/enhancements planned for v1.0, just like between v0.5 and v0.6, but there won’t be any other major releases before v1.0 (excepting v0.7 for development/a crutch to handle depredations/breaking changes that make there way into v1.0).

I would be interested in an update on whether 0.6 → 1.0 is feasible. There are an awful lot of issues in the 1.0 milestones. Besides, I thought there was going to be a proper beta release? (though perhaps that will just be called 1.0-beta)

It will be 0.6 to 0.7 to 1.0, but 1.0 will not introduce any new features over 0.7, only remove deprecations.

1 Like

What is the plan for the bugs in the 0.5.x milestone?
There are 77 currently open.

I doubt we are going to see a 0.5.2 ever.
So I had been assuming these would be in 0.6.

Was that assumption correct?

Is the 0.5.x bugs now the largest thing blocking a 0.6 (non-beta) release?

Or are they going to be blocking for 0.7, or 1.0?
Or are they going to be slowly patched sooner or later, and any that are serious enough to be blocking are already fixed?

But still a good question. BTW, the PR for v0.6:

1 Like