You heard it right, folks. The second release candidate for Julia v0.7.0 is now available. As usual, binaries are available for Linux (i686, x86-64, ARMv7), Windows (32- and 64-bit), FreeBSD (x86-64), and macOS. Get 'em while they’re hot at Download Julia in the “upcoming release” section. You can view the 0.7 release notes here and the list of commits included since RC1 here.
“But wait, RC1? What ever happened to that?” you may be asking. The release candidates are moving quickly and there were a couple of unfortunate issues with deprecations in RC1, so we decided to just blaze right through and get RC2 out the door. And here it is!
Just like its predecessors, 0.7-alpha, -beta, -beta2, and -rc1, 0.7-rc2 is a prerelease and should not be considered production-ready. It’s intended to give developers a chance to get ready for the full 0.7 release by trying it out and testing for issues. Most users should continue to use the latest release, 0.6.4, until 0.7.0 is fully released. Please report any issues you may encounter at Issues · JuliaLang/julia · GitHub.
Are you a package author? Does your package support 0.7 yet? If not, now is a very, very good time to get ready! You may also be interested in participating in our community-wide Upgradathon each Friday. If you test your packages with CI services such as Travis and AppVeyor, note that 0.7 will now be using RC2.
You may also have noticed that master is now 1.0.0-DEV. (We’re getting close!) Note that this now means that 0.7 and nightly are not both 0.7.0 prereleases in the Travis matrix, and it’s best to test on both.
We hope to see you at JuliaCon next week, and as always, happy coding!
I’m curious as to why this is called a “release candidate” if it is not release ready, to the best knowledge…
I know this has been the case with pretty much all the releases, but why not just continue calling these releases “betas” until there are no more known blocking bugs? Only at that point does a release candidate actually makes sense.
Are you responding specifically to this language: “0.7-rc2 is a prerelease and should not be considered production-ready?”
The way the release candidates work is that they are — to the best of our knowledge — ready for release. We want to make sure that they enjoy widespread use to hammer out any remaining show-stoppers, but we’re not ready to put the official release stamp-of-approval on it yet because, well, there may be some remaining show stoppers. So caveat emptor downloador, but please be a downloador!
If no major bugs are reported in a week or so, then the only change we’ll make to this release candidate is its name. It’ll effectively become the official release.
We’ve had a fairly long alpha/beta cycle for this release, so we’re trying to compress the release candidate cycle a bit, so don’t read this to mean “I have a few weeks to try this”. If you have something you want to try before the release, please test it now.
It seems (to me, from reading the PRs and issues from this cycle and the 0.6 cycle) that the releases that are called RCs do contain known issue that are left to fix, and that they should really just be called betas. Do you think when the rc1 tag was made, julia 0.7 was considered ready to be released?
Assuming no bugs, we thought it was ready. But there were bugs, so it was not and we fixed them. Also, we will sometimes do an rc even with minor known issues to be addressed in the next rc to give people a chance to get the rest of the fixes they may be waiting on. This is all standard software development practice. It’s also a signal for the kind of changes that may go into the release. E.g. at this point we’re no longer gonna add any deprecations (with the usual disclaimers that common sense supersedes policy). Additionally, rc1 has traditionally served as the branch point where master re-opens for (breaking) changes for the following release, with bugfixes being backported manually. Because CI wasn’t ready to handle the 1.0.0 version, we delayed the branch point this time to save some work. Also, 1.0 is special in that it doesn’t have any additional breaking changes (though we will start merging deprecation removals very soon to master).
Really, the point of doing all of these pre-releases is to signal milestones in development, and get people to seriously test their packages. Whether there’s an exact policy that specifies what does or does not count as an rc is mostly irrelevant to that purpose. From the user’s perspective, alpha => may want to start testing my package to see what broke, beta => good time to upgrade if you have the time, rc => better upgrade or your package may be broken on the release.
If I understand correctly: Part of the build process for the system image used to use a long list of functions to compile. Now, it instead is able to generate that list, which lets it add things like anonymous functions whose identity is highly unstable between commits (but consistent for a given build). And as part of generating the precompile statements, they’re also launching a REPL.
EDIT:
As for “release candidates”, I also want to point out that the Linux kernel normally goes through 7 release candidates as part of it’s schedule. Sometimes more, eg with Specter/Meltdown turmoil, but AFAIK they never plan on less.
I’m also a little confused by the release candidate designation. We have at least one bug that prevents us from running our test suite, and that is a bug in Julia not in our package. We did report it, but it has not been fixed in the alpha or rc phase (it’s a bug in type inference, which somehow broke between 0.6 and 0.7-alpha).
Is there a process to report issues like this that would be blockers for us supporting 0.7, for example. We can work around every instance of when this bug affects us (edit: we have a branch which does precisely this), but that only fixes the specific tests we have in our test suite. The user of the package would still encounter the issue randomly.
Or is there some later point in the build up to 1.0 where we should bring more attention to this sort of thing?
Ah, it may have slipped under the radar then. It’s [1].
It’s AbstractAlgebra.jl (pure Julia, no C libraries), not Nemo.jl, and was opened by my colleague, @thofma. However, the issue affects all our packages (including Nemo.jl) and is unfortunately a show stopper for us wrt 0.7.
Today at last we have individual workarounds for all the tests in AbstractAlgebra.jl that are affected by it, though not for the issue in general, of course. The next step is for us to fully characterise it, with a hopefully smaller test case. However, I think a couple of people have already indicated they know roughly what the underlying (type inference) issue is (unless I misunderstood).
Anyway, I was mainly asking here about procedural issues. How does a package maintainer draw attention to show stopper bugs? And how does that relate to RC status? For example there have been comments along the lines that the RC process is the right time to bring attention to issues like this not the alpha phase, or that bugs and even regressions are not necessarily blockers for 0.7. This has led to some confusion on our part about whether we should be making more noise, or whether we should be focusing on getting these sorts of issues dealt with at a different time in the build up to 1.0. We certainly understand that things are somewhat rate limited with regard to internals like type inference bugs and some patience is required on our part. On the other hand, we are really keen to at least support 1.0!