0.3.3 release planning issue

[staticfloat]

Our monthly stable release is looming. Please discuss the inclusion of issues into this release that haven't already been merged. The 0.3.3 milestone is set for Nov 21st, so let's shoot for that barring any big discussions on what to include.

[tkelman]

Should we backport #8734 ? @ViralBShah bumped OpenBLAS to v0.2.12 on release-0.3 for performance reasons, but I don't think we've backported the ILP64 compatibility fix (and subsequent makefile fixups).

release-0.3 has been pretty quiet for a few weeks. Here's a quick scan of some things from master that might be backport-worthy? Sorry for the massive ping, add the @juliabackports mention to the relevant commit / issue / PR if I mention you and you think that item is ok to backport.
4547cb7 @vtjnash backported
#9015 @amitmurthy backported
#8993 backported
#8940 has backport pending label backported
#8936 has backport pending label backported
#8902 if it applies cleanly backported
e5e489d I think the fix for this was backported but not the test backported
#8860 @staticfloat backported
#9000 @timholy backported
#8996 backported
#8976 @ViralBShah backported
#8942 @nalimilan backported
#8864 @staticfloat not ready yet, skip for now
#7814 @Jutho has a conflict, skip for now
a06e938 @ihnorton backported
c6bdbfe @nolta backported
#8982 @nalimilan backported
#8954 fix @nolta backported
anything else that's ready but awaiting confirmation of backport pending label? https://github.com/JuliaLang/julia/issues?q=label%3A%22backport+pending%22+

Also when it comes time to build the release binaries, it might be good to use a dedicated script to do so, instead of recycling the nightly build scripts which have been diverging a bit.

[ViralBShah]

I backported #8976
#8734 will open up many possibilities, so it is nice to backport.
We should also perhaps backport the enabling of the array RNG from DSFMT, but not the other API changes.

[tknopp]

@tkelman: Am I correct that you backported the fix for #8678? Or did this already land in 0.32?

[ViralBShah]

There have been a few documentation improvements recently. Should those be backported as well?

[tkelman]

@tknopp that one was backported by @ivarne in 5dda348

@ViralBShah any doc improvements that apply to release-0.3, yeah. Want to skim through the commit list and find any that haven't been backported yet?

[amitmurthy]

d9fb7e0 - the correction to fill documentation

[tkelman]

@amitmurthy thanks, done in 28e5f11

[ViralBShah]

I think that all doc related issues now are either backported or have the pending label.

[tkelman]

Okay, last thing on my list is #9050 then I think it's ready, modulo a few days of people other than me testing the big pile of backports I've pushed.

[vtjnash]

is this still open? might be worth adding ca7c4c8 and d194050

[tkelman]

we haven't tagged yet, but are those performance improvements or bugfixes? we haven't been backporting many other things that are just for performance afaik

[jakebolewski]

It would be nice to get in #8889 as well, I'm trying to find out why the Linux Travis build fails.

[ivarne]

We have backported performance fixes in the past, and I think those are prime candidates because they don't have the potential to break user code.

Then we have the issue of just sneaking in new functionality right before a release (especially functionality that fails on Linux). We would have to delay the release so that we have more time for release-0.3 followers to report issues. Ideally I think we should have the backporting rush right after a release, to give even more people the opportunity to test the changes before making an official release.

[staticfloat]

#8889 is pretty innocuous. It passes on all platforms now that it's equipped to handle Git's plethora of decimals. I'm going to backport that, then start the make release-candidate process, and see if everything works okay.

@vtjnash I think your two commits above are the only things in this discussion that are still undecided on. I don't know how your commits will effect stability, and I can't backport them as they have merge conflicts on release-0.3. If you could open a PR against release-0.3 we can see if they effect anything and if not, merge them.

It'd also be nice if someone could take a pass at the commit log since 0.3.2 and see if there's anything we need to add to NEWS.md. I've missed @mbauman's "This week in Julia", so perhaps we can stimulate a new post with a 0.3.3 release and a nice, concise NEWS.md.

[tkelman]

innocuous = contains 0.4-only syntax...

@staticfloat when you say "all platforms," did you test on all platforms? Calling Base.Git.version() on release-0.3 on Windows right now gives the following error

julia> Base.Git.version()
ERROR: `VersionNumber` has no method matching VersionNumber(::ASCIIString)

Please don't tag 0.3.3 until we're sure it works.

[ivarne]

I think I have fixed all issues with #8889 in 83f8018. There could still be more tough, but Travs seems to succeed.

[tkelman]

Better, but I still get the ENOENT on Windows.

[tkelman]

Damn, okay, it's #8942 breaking the pkg test on Windows because tempname() creates a file on Windows, but mkpath() in Pkg.init() fails when a file already exists where it's trying to create a directory. Related to #9053

[vtjnash]

i think we want JuliaLang/libuv#27 also. i forgot that it wasn't already merged, since I saw that it had merged upstream

[tkelman]

That even made it into libuv 1.0.0 which was just tagged a couple days ago. But considering it's not even merged in our fork and has been tested by probably at most 1 or 2 people with Julia, I would say it's 0.3.4 material at best. Unless we want to hold off another week or so for 0.3.3.

[tkelman]

I got the pkg test at least not showing any new failure modes that didn't exist in 0.3.2 on Windows, but I realize it still fails on 0.3 since we never backported #7590 - that was one of the first few 0.4 commits, it's a bit feature-y but also resolves a bug of not being able to delete read-only files (#7573). I'm a little on the fence about backporting it now vs first thing for 0.3.4, it's seemed stable enough for the past 3 months on master.

[staticfloat]

Thank you everyone for taking care of the syntax error I introduced on release-0.3. I'm ensuring that the two commits from #7590 don't cause issues, (I'm building this testing branch from absolute scratch on Windows, OSX and Linux as we speak) but this might take a while (windows I'm looking at you), so we probably won't tag until late tonight.

[staticfloat]

I have an insane sphinx version, it seems. (I thought our virtualenv magic fixed this? Or is that not backported?) Could someone with a decent version update helpdb.jl?

[ivarne]

@staticfloat Updated helpdb.jl in ac11aad

[staticfloat]

@ivarne many thanks. I have opened a PR here with the small tweaks to 0.3.3 which pass all tests on all platforms: #9120

As soon as I get the go-ahead from you two 0.3 guardians @ivarne and @tkelman, I'll merge that branch, tag 0.3.3, and start building binaries.

[tkelman]

no we didn't backport the virtualenv stuff. we could consider it for 0.3.4 maybe?

[staticfloat]

Alright, 0.3.3 has now been tagged. I'll work on binaries, hopefully we'll have things in place for a formal announcement in a day or so.

[nalimilan]

Fedora/EPEL RPMs are now in the Copr repo.

[staticfloat]

Thanks for your efforts everybody! Another release down. :)

[quinnj]

Yes, kudos to everyone helping the 0.3 releases. I think they definitely help keep a feel of "continuous" updating that was lacking in the 0.2 cycle (i.e. one big release and then nothing for a long time until 0.3 was released).

[tkelman]

but seriously, having the planning issue about a week beforehand was also really useful, let's do that again next time

[staticfloat]

FTFY

[StefanKarpinski]

That doctored up mem is brilliant.

[ViralBShah]

Love it!