0.3.5 release planning issue

[staticfloat]

Due to #9513, we've decided to push the 0.3.5 release up two weeks, shooting for this weekend for a new release. Let's discuss here what we want to try and include in this release. Although it is motivated by a single issue, I see no reason to avoid other fixes that have already been merged into release-0.3/are close to being merged. In short, this should be a fully-fledged release, not a targeted bugfix.

[tkelman]

There are roughly 25 issues or PR's currently labeled (by me, mostly) backport pending: https://github.com/JuliaLang/julia/issues?q=label%3A%22backport+pending%22+sort%3Aupdated-desc

Due to the abbreviated schedule we may want to make individual go/no-go decisions on backporting them into 0.3.5. Many are documentation-related, but not all.

Additional commits that were marked @juliabackports but don't have corresponding issues to apply the label to:

• had something here but it's covered by the labeled issue 9545
• the documentation parts of 68a09e0 that apply to release-0.3
• df846de ?

[tkelman]

For help with backporting, here's my preferred process:

1. Look over commit, see if any pieces of it are specific to 0.4 (UInt, AbstractString, etc)
2. Try git cherry-pick -x -e <sha> to see if it applies cleanly to release-0.3. The -x is nice since it adds a cross-reference in the commit message, -e is useful to edit the message to link to whatever PR or issue # it came from, or add [ci skip] for anything that's docs-only.
3. Resolve conflicts if any. For really nasty conflicts you may have to do the backport by hand. For the doc reorganization I had to turn a few changes into patch files, manually tweaking the patch file to move some hunks to refer to different files, cut out a line or two of context, etc before it would git apply.
4. make test locally
5. (optional) Push to a new personal branch if you want to check Travis on it. If you want AppVeyor to also test a commit before pushing it to release-0.3, you can either temporarily add the branch name to the whitelist in appveyor.yml, or make a PR for it against release-0.3.
6. Push to release-0.3
7. Revert if CI shows any accidental breakage caused by the backport
8. Leave a link to the backported sha in the corresponding issue/PR/commit comment
9. Remove backport pending label

[JeffBezanson]

I would be very conservative here. It would be quite unfortunate if a release to fix a regression itself had another regression.

[tkelman]

Right, makes sense to me. We can finish doing some or all of the doc / test-coverage improvements but postpone most of the rest.

[ViralBShah]

Yes, doc/test-coverage are good to backport for this release.

[tkelman]

Okay, I got almost all of the obvious ones. Can someone else please

A) check my work
and
B) take care of, probably in this order: the documentation parts (not the deprecation!) of 68a09e0 that apply to release-0.3, then manually do the equivalent of f910cd0, then the equivalent of 0b5811d

[tkelman]

Whoops, sorry, apparently gcd(::Int32, ::Int32) returns Int on release-0.3, my local tests were on win32 so missed the failure. I'll have to comment out some of the backported tests that fail on 0.3.

edit: fixed by 2508fcb

[staticfloat]

• Documentation part of 68a09e0 backported in c951564
• Profiling docs reorganization from f910cd0 backported in 0a73933
• stdlib/profile.rst cleanup from 0b5811d backported in 75df2f1

[staticfloat]

I'm going to run a make release-candidate on my machine, we'll see how it goes.

[tkelman]

Last doc change that might be ready would be git diff 76c991d7~ 76c991d7 | sed -e 's/nothing/false/g' | git apply && git add doc/manual/control-flow.rst && git commit -C 76c991d7 && git commit --amend (then add sha x-ref) from #9320.

[jiahao]

Would be nice to squeeze in an update to the Unicode table after #9584; simply run doc/tabcomplete.jl and pipe its output to doc/manual/unicode-input-table.rst. On current master, the latter does not compile with Sphinx due to a 'malformed table' error.

This step could also be automated as part of the release-candidate build target...

[staticfloat]

Also, we have a bit of a problem with sphinx; since it doesn't understand multiple dispatch, it's mad that we have a Base.length() defined in arrays.rst as well as collections.rst. Thoughts on how to fix this? Should we link to just one?

[jiahao]

I say ignore the warning; despite it, Sphinx generates cross-references to duplicated functions in the index (look at _build/html/genindex.html), which actually works nicely in our favor. We won't be able to use pedantic mode (SPHINXOPTS="-W") anymore but I think it is a small price to pay.

[tkelman]

@jiahao I did partially backport the documentation of the current status of unicode tab completion support, and regenerated the unicode-input-table.rst in that backport, but #9584 and an earlier one of @stevengj's PR's that added a large number of unicode symbols were not yet backported. Now might not be the best time to do so.

[jiahao]

@tkelman you can always run tabcomplete.jl on the release branch separately just to make sure the table builds. Looks like that's what you did, so I think that would suffice.

[staticfloat]

We are set to treat warnings as errors right now. Should I disable that?
The doctest fails at that point with the current situation.
-E

On Tue, Jan 6, 2015 at 2:12 PM, Jiahao Chen [email protected]
wrote:

I say ignore the warning; despite it, Sphinx generates cross-references to
duplicated functions in the index (look at _build/html/genindex.html),
which actually works nicely in our favor.

—
Reply to this email directly or view it on GitHub
#9631 (comment).

[jiahao]

@staticfloat Yes I think removing -W is the solution here.

[staticfloat]

Okay, weird. I ran it a second time and it passed. I think I must have been confusing two separate things here.

make release-candidate passes on my machine on f1b8633 now, so that's good.

[tkelman]

Nobody objected to that last doc change (#9631 (comment)) so I just backported it. I think we should be okay to tag now?

[staticfloat]

Yeah, I think we're good here as well. I'll run release-candidate once more to be certain and then we can tag it and bag (err...build) it.

[tkelman]

pause. need to backport a bugfix that tim just committed to master

[staticfloat]

I also found a doctest failure.

[tkelman]

got the bugfix in 2d894e5, carry on

[ivarne]

Can we get 23424b7 as well. It seems relevant, but I have not tested it.

[staticfloat]

Yes, I agree that 23424b7 looks good to have, especially given that this release is partly due to embedding concerns. I'll grab that in as well.

[staticfloat]

Tagged in a05f87b. Binaries building now. @nalimilan I don't know if you've been following this at all, but it's time to work your RPM magic.

[waTeim]

Tested against the Linux and jl_ctx_base error is fixed but now there is a new one

fatal: error thrown and no exception handler available.
ErrorException("Module: too many arguments (expected 1)")

about halfway through my tests.

Not sure if this is my error yet caused by the mod i made for my own stuff in #9661, have not debugged thoroughly, is this the right thread for this?

[waTeim]

That error was due to my workaround, so with the fix for #9661, in place I reverted, and all tests pass. So I've verified at least as far as my stuff is concerned.

• 3.5 (Linux) is fine as is
• jl_new_module is usable in 0.4, and it's probably a good idea to back-port like you're already doing.

I'll test OS/X as it becomes available but I'm confident it will pass too.

[tkelman]

If you could provide reproduction steps that might help. Looking at the Travis results on your node-julia repo it looks like @staticfloat may still need to update the http://status.julialang.org/stable links, at least for OSX?

[nalimilan]

RPMs are OK now.