Hello all! The latest bugfix release of the Julia 0.5.x line has been released. Binaries are available from the usual place, and as is typical with such things, please report all issues to either the issue tracker or on discourse.
This is a bugfix release, see this commit log for the list of bugs fixed between 0.5.1 and 0.5.2. In particular, if you’ve been having issues with Pkg installation errors, an upgrade to 0.5.2 should resolve those. Let us know if not. If you are a package author and want to rely on functionality that did not work in the 0.5.0 or 0.5.1 releases but does work in 0.5.2 in your package, please be sure to change the minimum julia version in your REQUIRE file to 0.5.2 accordingly. If you’re not sure about this, you can test your package specifically against older patch releases on Travis and/or locally.
This is a recommended upgrade for anyone using previous releases, and should act as a drop-in replacement. If you find any regressions relative to previous releases, please let us know.
We’ve also tagged the first release candidate for 0.6.0. You can use “0.6” on Travis, or “0.6-latest” on Appveyor, and it will use the most recently tagged release candidate. We have branched release-0.6 off of master, master is now 0.7-DEV (see https://github.com/JuliaLang/julia/pull/21610 for an explanation, 1.0 is planned to be functionally identical to 0.7 but with deprecations removed, and released very shortly after) and open for breaking changes. Please report anything that has regressed since feature freeze. We will be doing backports of bugfixes to release-0.6 for further release candidates roughly once a week until there are no known release blocking issues left. We’ve had a few little bugfixes on master, but nothing critical yet to my knowledge, and the only major TODO item left is a pass through the release notes in NEWS.md and make sure all the deprecations and breaking changes in 0.6 are noted.
-Tony
28 Likes
Is there an easy way to perform the upgrade from 0.5.1 to 0.5.2 for a JuliaPro user other than downloading and installing JuliaPro again?
Not currently. JuliaPro has its own separate release process and I anticipate it will take at least a few days to build an initial 0.5.2 based version. JuliaPro doesn’t have upgrade in place functionality at the moment but that is something we’re looking into as a future feature.
2 Likes
Thanks for the clarification. I am a MATLAB old-timer but a Julia newbie.
I just saw by coincidence that RC2 was released on Thu. Was that announced anywhere? They really should be announced, otherwise package devs like myself won’t know about them and won’t test them, which kind of defeats the purpose 
. CC @tkelman.
Cheers,
David
3 Likes
I agree. It seems that that there doesn’t seem to be a concerted effort to make 0.6 builds readily available (pre-built) as release nears, in order for package devs to be able to test with up-to-the minute fixes.
The builds are available, release are visible in Releases · JuliaLang/julia · GitHub.
What are you missing?
There was a PR where the RC backports were prepared and tested, which was merged and tagged late Wednesday. The binaries were built and uploaded to S3 on Thursday, and links on the website updated shortly after (website PR opened Friday, merged Saturday). Though if you’ve been using “0.6” on Travis or “0.6-latest” on AppVeyor, as described above, then you’ve been testing RC2 with any builds since the S3 upload on Thursday. I hadn’t sent a discourse announcement yet. There’s not that much to announce - the release notes are much more complete than they were at RC1 thanks to Sacha Verweij, a few bugs have been fixed (see https://github.com/JuliaLang/julia/compare/v0.6.0-rc1...v0.6.0-rc2), and there are one or two newly-identified blocking bugs on the milestone now.
1 Like
I had been asking for more frequent builds of 0.6 than just the RCs.
If you need these rapid updates, why don’t you just build locally?
5 Likes
I could do that, but others might not be able to, easily. This is a task that could be automated (and IMO it should be). I just don’t understand the resistance to having these builds available.
Because they are not checked for performance regressions or that they do not break packages. Having those readily available would do more harm than good.
2 Likes
This discussion fits more with https://discourse.julialang.org/t/0-6-nightlies than with this topic, it may be worth splitting the thread.
Since people appear to be using the release branches for day-to-day-work (the readme recommends it, which maybe we should change), I’ve gotten more cautious over time about merging things to release branches that haven’t been fully regression tested against packages and the benchmark suite. So I tend to do backports in large batches right before a release - people are welcome, encouraged even, to help out with testing while those are under preparation, and I do trigger binary builds of those branches for testing purposes. Watch the PR’s and set an email notification filter for “[release-0.*]” or “backports for” if you want to be notified of those while they’re in progress.
We have more pressing things to deal with when it comes to buildbot configuration, like rearchitecting all of them, to worry about adding nightly builds off of a branch that currently isn’t configured to do so. There is a new @jlbuild functionality that’s being worked on where people with commit access can more easily trigger buildbot jobs for given commits, branches, or pull requests. A nightly comment on the latest state of the release branch could accomplish what you’re asking for, but you won’t get much of anything different from the latest release until the next fully-tested batch of backports are being prepared.
I think it is still really important to make an announcement to discourse when there is a new build. It seems really important that folks actually test their code on the RC so that any regressions can be found, and at least I will need a specific trigger for that. I have packages that I don’t work on regularly, so they won’t be tested on travis and appveyor unless I trigger a build, and I won’t if I don’t know that there is a new RC build that you guys want to have tested.
Cheers,
David
4 Likes
If properly marked, anyone using these builds would be aware of caveats, so I don’t see how this would harm anything.
Agree, if you batch the backports up until just before the a new release more frequent binary builds don’t make sense, but I thought I remembered fixes going in at least every other day between RCs. Anyhow, if you’ve got your hands full, I don’t meant to get in the way of anything by whining. Hopefully, the auto-build workflow can be worked on for future releases.
There are two different discussions in this thread, IMHO it should be split. I agree it would be nice with an update when there is a new RC for package maintainers working to get everything 0.6-compliant in time.
David, i agree, that announcements on discourse should be up-to-date and i guess no-one disagrees, but at the same time i see how overloaded the dev team is in creating releases, so i’ve decided to put a few github pages in my browser into tabs and reload. Maybe it’s also possible in github notificaitions to show up.
If you follow julialang.github.com, you’ll get these updates quicker, and that repo is much quieter.
3 Likes
Hi — just to let you know the link to " NEWS.md" misdirects, it goes to some medical site. Hope this isn’t a general issue! Henri
Thanks for the heads up — I’ve edited the post. For some reason Discourse decided to auto-link NEWS.md, as though every foo.ext is a domain to be linkified. Not sure what’s going on here — it doesn’t happen with NEWS.md in this post. I wonder if md was whitelisted as a TLD back when Tony initially posted it.
In the future, you can just flag the post to ensure quick moderator attention.