Status update here: the biggest outstanding items are in Things we should deprecate, 0.6 edition, notably and by far the most important being changes to inner constructor and method parameter syntax. This change addresses one of the most confusing and problematic aspects of Julia currently. This change must go into 0.6 so that there can be a deprecation cycle and we can reclaim some of the current syntax in 1.0. Sorry for the delay in getting 0.6-alpha out!
9 Likes
I think it’s really helpful that there’s a roadmap/master list of tasks! 
no rush. take the time to get it right!
5 Likes
Hi guys,
I’m trying to prepare the openSUSE package for the future 0.6 release. Can anyone point to me please where can I get the closest source code to v0.6 available today? Is it git master?
1 Like
Yes right now v0.6 is still being developed on master.
1 Like
Thanks! The openSUSE package for 0.6 series is already done:
https://build.opensuse.org/package/show/home:Ronis_BR/julia-unstable
We should have a very short time between release and availability at official repos.
3 Likes
Another update: there are now only four feature changes remaining for 0.6 – the top four on https://github.com/JuliaLang/julia/milestone/20. Of course, a couple of those are pretty major, e.g. the two issues constituting “the great type keyword rename”. Actual feature freeze is imminent.
5 Likes
Ok, as far as I can tell there are no feature or deprecation items left in the 0.6 milestone. Let’s declare “last call” for 0.6 features — if you have a feature/deprecation PR open that you want considered for 0.6, bump it or add it to the milestone now. I think anything added at this stage will have to be fairly complete though. Shall we expect to declare feature freeze by Thursday?
8 Likes
Out of curiosity: The issue list currently contains 42 issues marked ‘breaking’, 63 marked ‘decision’, with 20 marked both, and at least half date back to the year 2015 or earlier. However, some are marked for the ‘1.0’ milestone. What will happen to these? Will there be another round of (major) breaking changes before the 1.0 release, or after 1.0?
Also curiosity: will any of the Nullable Redesign Julep make it into 0.6?
3 Likes
Yes, many of the breaking items will be addressed for 1.0, and probably many will just be decided against and closed.
We’re now at feature freeze and 0.6.0-alpha should come out shortly – whenever @tkelman gets the appropriate testing and incantations done.
That means it’s now time to get packages working on 0.6!
Regarding the schedule for the rest of the release, I suspect we can compress the remaining timeline for 0.6 and get 0.6-beta out in a couple of weeks, leaving us only a month behind schedule, and if the RC phase goes smoothly, we might even catch up a bit more. 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), so it’s pretty much just Julia bugs we need to worry about, which is much easier to control.
20 Likes
1 Like
The last Windows nightly binary is still before #19825 so using Pkg.update() on Windows causes Julia to stall.
Is there an estimate on when a new build will appear? I’d like to give the latest v0.6 a try to update some packages, but this problem has halted that.
1 Like
the windows build issue should be fixed by https://github.com/JuliaLang/julia/pull/20713, should get new windows nightlies shortly
3 Likes
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.