Build release tags on Travis

[tkelman]

this should hopefully result in automatic docs deployment to release-0.6

cc @mortenpi @MichaelHatherly is this right, will travis builds from a tag just do the right thing to gh-pages here? It looks like 0.5.1/0.5.2 might need to be built and committed manually to gh-pages for release-0.5?

[ararslan]

Speaking of the 0.6 docs, I believe @mortenpi has been working on updating Documenter such that the new 0.6 syntax is highlighted appropriately. It would be great to get that into the docs build, however that needs to happen. (Sorry, a little OT)

[tkelman]

Once there's a tagged release of Documenter available with that new feature, that gets upgraded by adjusting the version bounds in https://github.com/JuliaLang/julia/blob/master/doc/REQUIRE

[mortenpi]

Documenter 0.10.1, tagged a few days ago, contains the highlighting fixes. There are a few code blocks in the manual that could use the new julia-repl highlighting as well.

As for tags, it should work, but all tags will get deployed to stable, including *-rcX ones, I believe. Documenter checks if TRAVIS_TAG is set and then simply deploys to stable. If the tag is a version number (matches Base.VERSION_REGEX), then it deploys to vX.Y.Z and release-X.Y directories as well. But RCs should match that regex as well.

I think this is too simplistic for the base docs. Workaround could be to only enable exactly v0.6.0 branch on that branch. But in general having RC docs deployed would be nice as well, so I think this needs a bit of refinement on Documenter's end.

0.5 docs are still on Sphinx, right? In that case Documenter can't really help. It seems that @MichaelHatherly was pushing those manually if one looks at the gh-pages commit history.

[tkelman]

It's fine for now, since release-0.6 is the only branch using Documenter that we'll be tagging anything off of for a bit. release-0.5 still uses sphinx, yes. Guess I should manually build the docs and commit the html files for 0.5.2 then.

By the time we tag an 0.7.0-alpha it would be useful to have something a bit cleverer, to avoid stable alternating between 0.7 prerelease tags vs maybe concurrent 0.6.x backport tags.

[mortenpi]

There will not be any more RCs for 0.6? With this the next RC would overwrite the 0.5 stable docs.

[tkelman]

Oh, yes there will be an rc2 shortly. Almost stable, though guess we could tighten a regex somewhere and only push to stable for tags without any prerelease annotations?

[mortenpi]

Dropping the (-\S*)? bit in .travis.yml ought to work as well, I guess? That way we don't build docs here for the -rc2 tag.

[tkelman]

I was thinking it would be worth deploying prereleases to their respective release-x.y sections, but skipping them works for now

[mortenpi]

Agreed that that is how it would ideally work, but that would require some changes to deploydocs, and I don't want to block the 0.6 release schedule 😄

Although, perhaps release-x.y should be for full releases only. I am thinking how should one handle a hypothetical v0.6.1-rc0 build. I feel that the release-0.6 shouldn't get overwritten until the actual v0.6.1 comes along. But it also implies that release-0.6 doesn't get created until v0.6.0 proper is tagged.

The RCs would still be in their dedicated vx.y.z-rcN directories, which is probably good enough.

[ararslan]

The latest docs build looks great! It appears that things are highlighted correctly now, but @mortenpi's changes to the default monospace font don't appear to be reflected.

[mortenpi]

The font changes were not in the patch releases, we need v0.11.0 for that. But ideally we'd have those as well when 0.6.0 comes out.

[KristofferC]

v0.11.0 is also the mobile improvements? Would be very nice to have that in as well.

[mortenpi]

Yup. those too.