goal: RC1 today

[Jeff Bezanson]

I think we should try to tag a release candidate today.

The only remaining issue is #12967. @vtjnash has been investigating
this, and I think we are close to a resolution. The crash is in JLD,
which does some very hairy low-level operations. The issue can be
worked around by fixing some code in JLD, and after that I don't think
this is release blocking.

I know there are a lot more fixes we can do, but I can't imagine
holding up the RC until, for example, every doc string is perfect. If
anybody has a good reason to delay an RC more than, say, 12 hours,
please speak now.

Is `make release-candidate` in working order?

-Jeff

[Milan Bouchet-Valat]

Could we try to get https://github.com/JuliaLang/julia/pull/13000 or an
alternate fix in the RC? This is going to be a nightmare for all
packagers.

Not that it's strictly needed for a RC, but if we take as a principle
that it could theoretically end up being the final release...

Glad to see it coming!

[Jeff Bezanson]

Ok, thanks for bringing that to my attention. Issues like this that
interfere with packaging are the perfect kind of thing to address
right now.

[Tony Kelman]

No, `make release-candidate` will fail right now due to a few linkcheck problems. One is a unicode bug in python 2 and/or sphinx due to a latin-1 nbsp in valgrind's docs, which none of the sphinx maintainers have triaged yet in the 24 days since @garrison reported it upstream. https://github.com/sphinx-doc/sphinx/issues/2003. This could be fixed either by using python 3 for linkcheck, or commenting out linkcheck from `make release-candidate`.

The other linkcheck issue is that almost all of the line-number links in doc/devdocs/init.rst are out of date (some fail linkcheck due to init.c being shorter than it used to be) and should probably just be removed.

Openblas has an uninitialized-memory bug on old processors, #12907, but I think the only new part about that is the cholesky tests recently started triggering it in a reproducible way. I'd like to fix this for final if we can find a low-risk way to do so (it may require a newer upstream release of openblas to be tagged), but it's not RC-blocking.

[Tony Kelman]

Many of the doctests are also failing due to their backtraces now having lines for eval_user_input and _start in client.jl.

[Maxim Grechkin]

What about https://github.com/JuliaLang/julia/issues/12939 ?

It breaks Patchwork.jl (https://github.com/shashi/Patchwork.jl/pull/9) and Escher.jl by extension.

On Tuesday, September 8, 2015 at 1:07:20 PM UTC-7, Jeff Bezanson wrote:

[Jeff Bezanson]

That will be important to fix, but it's not release blocking. It can
be fixed during the RC period, or in 0.4.1.

[Jeff Bezanson]

Ok, almost everything in make release-candidate passes now. As noted,
linkcheck is one exception. Another is netload, where I get

```
Testing create_strings...priming process...priming process...ERROR:
LoadError: UndefVarError: get_vmsize_rusage not defined
in run_mtest at /home/jeff/src/julia/test/netload/memtest.jl:36
```

The function in question seems to have evaporated?

[Elliot Saba]

I'm not sure how that ever ran, but changing get_vmsize_rusage() to get_vmsize() runs.  It seems that the memory usage statistics probably aren't capturing what we want since the first time I ran it, it showed 0KB mem usage difference, and the second time I ran it, it showed 69MB.

-E

[Jeff Bezanson]

Ok, starting from e9f4e201cdc7ed85710a9ff60d882fdc8a58d297 I intend to
bump versions to 0.4.0-rc1 and branch.

[Jeff Bezanson]

I am pleased to announce that we now have a release-0.4 branch, and
0.4.0-rc1 is tagged (e5c6964a497a71fb940117530c1867ddd71f4c67).

release-0.4 is open only for critical bug fixes. master is now open
for bug fixes and changes of moderate size and risk. Let's keep master
relatively quiet until 0.4.0 final, to facilitate backporting.

The tip of the release branch is
70ed3928ca6433484318d36a8e80134d8b5f85d1; there I have updated all
version and branch info AFAIK. The release-candidate steps in the
Makefile said to update branch names after tagging, so that's what I
did, but only the release-0.4 tip and not the 0.4.0-rc1 tag has all
version info updated. Hopefully this is ok since we will need a new
tag for the final release anyway.

Elliot, are you available for a round of packaging? I have not done
the source-dist and binary packaging steps on the list. Let's focus on
shaking out any build/package/install issues.

Thanks everybody for your perseverance on this release. I know it has
been frustrating at times.

-Jeff

[Tim Holy]

Yay! This is gonna be awesome.

Would be great to get the nightlies to follow release-0.4 until the release
happens, so that it's used for all package testing on Travis. I've already got
a couple of PRs queued up over at Gtk that won't pass until a new nightly
comes out ;-)

--Tim

[David Anthoff]

Thanks so much for all the hard work!

Once binaries are up on julialang.org, it would be good to announce this on julia-users as well and get as many people as possible to stress test this.

Cheers,
David

[Tony Kelman]

Buildbots are pretty borked right now. Making nightlies off a release branch is also not really set up currently. What we'll probably do is move RC binaries to 0.4-latest on S3 once they're ready so you can use "0.4" in your .travis.yml for package testing.

[David Anthoff]

Yes, I just realized that downloading a nightly from julialang.org (at least for Windows) gives me a 7 days old master.

 

I think the 1 week timeframe that was mentioned previously (i.e. we release a RC and if we find no new bugs for a week we declare release) has to start once the binaries on julialang.org have the RC, and then once the announcement to julia-users has been made.

 

Cheers,

David

[Elliot Saba]

The buildbots are crunching away on the latest binaries, we should have something up by the end of the day.

The Windows binaries are a funny story; they're getting built just fine, but the success reporting code was having a problem making an outbound HTTPS connection.  I have just implemented a workaround that should hopefully get that automatic uploading back on track.

Note that since 0.4 has forked and master development is now on 0.5, downloading the latest "nightlies" will download a 0.5 build.  Once the 0.4-rc1 binaries are available, we will be advertising those in their own separate space on http://julialang.org/downloads. 

-E

[Páll Haraldsson]

Great!

julialang.org homepage still shows 0.3.7. I understand there is a performance boost for many things. It's not a priority, but when released re-run numbers? I know the GC is improved, would help for stuff, but not sure for microbenchmarks (that try to avoid GC..). Strings are also faster (thanks, you know who you (all) are..). I'm sure there are other improvements for speed/accuracy for math, that I know less about and not my area, but still happy for you all.

[In case, the speedups do not show in these benchmarks,] maybe someone needs to write something about other improvements, worthy of the homepage?

At least I'll now be less silent on the Keno's great Cxx.jl FFI..

-- 

Palli.

[Milan Bouchet-Valat]

Le mardi 08 septembre 2015 à 16:17 -0400, Jeff Bezanson a écrit :
> Ok, thanks for bringing that to my attention. Issues like this that
> interfere with packaging are the perfect kind of thing to address
> right now.

This one would also be nice to fix for 0.4.0 or soon after it:
https://github.com/JuliaLang/julia/pull/12779

It will force packages to remove an architecture dependent file from
/usr/share/, which will make the test suite fail when run from the
installed Julia:

(Unfortunately, my PR wasn't correct, and I won't have the time to find
a better solution before about one month.)


Regards