tagging releases for v0.6 and v0.7

[ExpandingMan]

I think it is long past time that we tag and announce this thing.

I have the following plan for release. I have just created a v0.4.0 tag (this should NOT be a release yet although for some reason the tag shows up in the releases section in github, although it is not labeled latest release). This tag is fully compatible with 0.6. I have made a single commit since that tag. What this commit does is remove __precompile__ (as this is now the default) and fixes a couple of errors and deprecations in the 0.7 tests. I suggest we tag this as v0.4.1. In the release notes we will inform users that we recommend that they use v0.4.0 on Julia 0.6 and v0.4.1 on Julia 0.7. All future development will then abandon 0.6 compatibility. I have already done this on Arrow.jl.

This package is a critical part of my workflow and I make read and write calls with it hundreds of times a day, and I have no problems. Together with the unit tests I'd say this package is in a pretty good state. I know @quinnj said there was concern that we are missing some DataStreams feature, but at this point it has been so long since a tag that I suggest we save those changes for a v0.4.2.

Thoughts, suggestions, comments?

[davidanthoff]

Why not have v0.4.0 the last release that supports julia 0.6, and then a v0.5.0 that only supports julia 0.7? And not have any release that supports both? That seems by far the easiest option? Also, if you drop support for a julia release, you need to at least increase the minor part of the version, otherwise the METADATA police will complain.

Oh, and just as a side note: FeatherFiles.jl has been using your work in Arrow for a couple of months now in a released version, with the whole streaming Query.jl integration that I mentioned etc.

[ExpandingMan]

The reason that v0.4.0 and would support both 0.6 and 0.7 is because the code currently in master already supports both and does not require any changes (it gives a single deprecation warning in 0.7). Again, I'm suggesting that v0.4.1 would be the version which supports only 0.7 (technically it works on 0.6 it just doesn't have __precompile__). Are you saying that METADATA will make us have the 0.7 support version at v0.5.0?

[ExpandingMan]

Seems you are right, we need to change the middle number between Julia versions. So the new proposal is v0.4.0 (the currently existing tag) for 0.6 and v0.5.0 for 0.7. That would give people the ability to make patches for the 0.6 version if they wanted.

[quinnj]

Sounds like a good plan to me 👍. I'm working on DataStreams now, but I'm happy to fix it up in the next week or so and then we can tag a new release.

[ExpandingMan]

You're working on DataStreams changes to Feather or DataStreams itself? Do you want to wait until you're done to release, or do you want to do it now?

[ExpandingMan]

Note I deleted the existing tag. This way we can tag both v0.4.0 (0.6) and v0.5.0 (0.7) on whatever is the commit we decide on (everything should still be ok on both versions now).

[quinnj]

Let's go ahead and tag now; no need to wait for DataStreams; I'll update it as I finish it.

[ExpandingMan]

Nice!

Ok, listen up anyone who's interested. The current master should work on both 0.6 and 0.7.

Sometime tomorrow afternoon I will tag the current commit as v0.4.0 (as a release), make a commit that only changes the REQUIRE to have julia 0.7- and Arrow 0.2 and tag that commit as v0.5.0. Please let me know if there are any issues.

[davidanthoff]

I don't see an issue, but I also don't see what you gain from having a v0.5.0 :) As far as I can tell it should be enough to just tag v0.4.0, and be done with it?

[ExpandingMan]

We can wait until we have another commit that actually requires the separate tagging if you prefer, I suppose that would make more sense.

Literally the very next commit I make to this package will not support 0.6 so I expect that to happen relatively soon.

[ExpandingMan]

I'm trying to rebuild the docs but am having some problems. Will get it done sometime soon...

[ExpandingMan]

Ok, I definitely have no clue how github.io updates the docs. Most sites don't even seem to commit their docs/build directories. Is there some bot that's supposed to do this? Because if there is that doesn't seem to be happening. Do we need to change the url to the link in the README?

[KristofferC]

Documenter runs on merges and pushes the rendered docs to gh-pages branch.

https://juliadocs.github.io/Documenter.jl/latest/man/hosting/

[ExpandingMan]

Well, a commit has been pushed and nothing seems to be happening, I'm still seeing the old docs. Any ideas?

[ExpandingMan]

Ok, sorry for making so many small commits but I think I've finally fully figured out the documentation. The problem is, travis doesn't seem to have the cryptographic key it needs to push the changes to the documentation. As you can see in the linux, Julia 1.0 travis build, the environment variable DOCUMENTER_KEY does not exist.

I do not think I have the proper permissions to add one, as I cannot access https://github.com/JuliaData/Feather.jl/settings/keys.

So, @quinnj , do you know why this may have broken, would you mind going ahead and setting this up?

Sorry for hanging this release on the documentation, but I want to make sure the tagged commit gets the proper documentation it needs, as I believe we owe users at least the bare minimal documentation that I wrote.

[ExpandingMan]

Also need to resolve this tagging catastrophe that I caused with Arrow before tagging.

[ExpandingMan]

Hello all I

• Fixed the docs (somewhat manually).
• Cleared up the Arrow package management clusterfuck (which was partially a local issue on my part).

I have tagged Arrow v0.2.1 in which I deleted the Project.toml which had an incorrect UUID.

As soon as that is merged in METADATA, I am going to tag this and announce it on discourse.

If there are any objections, you should speak up now.