Continuous Release: remove 'dev'?

[keflavich]

The continuous release process was established in #1124, but it doesn't fully "work" yet because we're pushing .dev releases to pypi, which means that pip install astroquery doesn't install the latest version of astroquery.

So, what is the appropriate way to make this a fully automated release process? Can we just drop the 'dev' from the version name? Does that break some of the astropy-helpers machinery?

cc @eteq, @bsipocz

[bsipocz]

pip install --pre astroquery should work though.

I'll look into it how to both have the cake an eat it ;)

[bsipocz]

OK, my only reservation with removing the dev tag was that we may still want to have tagged versions. Those are the ones where we made some extra care to clean up the changelog, or made sure as many things as possible pass the remote tests, etc. And they can be then more easily conda/linux packaged.

But if we figure out a way to structure the changelog, I'm in for dropping the dev suffix and either have one more digit, or start the version number increase from 0.3.9

[keflavich]

Yes, I still want tagged versions. We can associate those with "minor" releases.

Should the versioning continue as 0.3.9.12332512354?

[bsipocz]

That's easy to do, but then the logic say 0.3.9 predated 0.3.9.12332512354.

Shall we just skip 0.3.9 and go to 0.3.10 next? Then we should be all good to go right now.

[keflavich]

yeah that's the way to do it

[bsipocz]

I'll look into helpers then how to increment the last digit automatically.

[keflavich]

Question: does our current continuous deployment approach work with conda? Right now, it looks like all of the conda channels have v0.3.8 as the latest:
https://anaconda.org/conda-forge/astroquery
https://anaconda.org/astropy/astroquery

[bsipocz]

No, the current approach could only work as a prerelease, that would end up on a different channel. See conda-forge/astroquery-feedstock#7

[eteq]

This problem has reared its ugly head when users asked me about it several times recently, both in the conda context and for people who don't expect/want to use --pre. So here's two proposals I'd like to suggest:

1. Have all versions be of the form x.y.nnnn, where n is the number of main-line commits - basically what the helpers machinery does for the "dev" case, but using a PEP 440-compliant release version that pip won't think is a pre-release. This might be implementable by just having the version in the actual source code be x.y and then do a version.replace('dev', '.') in the version.py?

2. Have all versions be of the form x.y.z, where z is auto-incremented. This would involve adding a script that executes on travis which pushes a commit onto github incrementing the version and only after that does it do the actual deploy. I suppose it would also need to push a second commit that switches things back to dev=True?

In both schemes, x.y is incremented whenever a "tag" is declared (that one is also tagged), and some flag (equivalent to the current dev flag) is used to indicate that release is a tag (and something probably needs to be done to stop the "back to development" release from auto-releasing, although that could be just a [nodeploy]?)

With 1., the two downsides are that there can be large apparent jumps in the version number and that it's possible to seriously mix stuff up on developer branches. The jumps don't bother me that much because it doesn't seem that different from, say date-based versioning... but still. The dev branch thing might be more annoying to some, although I avoid it by never installing a dev version (I always use python setup.py build/test), and we could recommend that in the dev guide...

For 2., the biggest downside I see is that the script that would be needed I fear would be rather brittle and would probably eat a fair amount of travis time. It would have to do something like on each merge into master, run once to push up the new version, run again to do the deploy, and perhaps yet one more time (with [nodeploy]) to switch back to master. Perhaps some cleverness could simplify that into just two or even one travis run, but that would come at the cost of maintainability (and the danger that's inherent in having a script that pushes back to master...).

I think I favor 1. because the downsides don't seem as bad... but opinions may vary.

cc @bsipocz @keflavich

[bsipocz]

As I recall we were thinking about 1), but then the machinery in the helpers is not really doing what both of assumed it does (astropy/astropy-helpers#398).

So now I'm more inclined to do something along 2), have an strictly increasing version number bumped exactly one by the new releases. I think I can do it all via travis without much overheads, but just hasn't yet got enough time to sit down and do it.

[bsipocz]

So, what about:

• We do option UKIDSS query tool #2, x.y.z, in the deploy step travis changes the z in the version number for pypi, and deploys, but doesn't push it back to github where it stays as x.y+1.dev.nnnn?
  And if figures out z from the last one pushed to pypi and increases it by one.

[keflavich]

I think that option is fine, but it would be nice if we could mention something about the release version in changelog entries, which won't really be practical with this approach

[bsipocz]

What about putting the merge commit's hash in the README or setup.py or etc?

we also don't seem to have a description any more, but that hash (and the fact that a release is auto deployed) can be added to the description. https://pypi.org/project/astroquery/#description