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?
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.
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.)
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.
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.
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)
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?