dev version numbering is nonsequential

[bsipocz]

As astroquery has switched to continuous deployment, currently using the dev version numbering (x.y.devz) it became apparent that z in the version is nonsequential for master merges.

I see how two commits on two separate branches can have the same version number if the base of those branches is the same, but we saw this issue for the merge commits, too (see the dates of the releases here: https://pypi.org/project/astroquery/#history). I haven't investigated into the details, I can imagine it may still be an issue of travisCI (that we use for the deployments), but nevertheless the problem deserves an issue here.

cc @keflavich

ps: We plan to switch away from using the dev version to do something more sequential for deploying, but that is yet to be implemented.

[pllim]

😱 This is bad news for anyone that uses helpers and decide to do continuous release. Not just astroquery!

[pllim]

Would this be naturally solved if #420 decides that version helper should no longer be part of astropy-helpers? 🤔

[bsipocz]

I'm a bit ambivalent of bringing in extra dependencies, but a solution is definitely needed.

[bsipocz]

So at least I have figured out what goes wrong here.

The version number generation basically does a git rev-list --count HEAD to figure out the version. This would be roughly incremental, parallel branches could share the same version number, so it's only useful if used along with the branch.

BUT, and it's a serous but. Travis (and maybe other CI, too) does a shallow clone rather a full one, so this logic is always messed up.

E.g.

 git clone --depth=50 --branch=master https://github.com/astropy/astroquery.git astropy/astroquery
 cd astropy/astroquery
 git checkout -qf 32741121645692b3501b6da5137f4ae09064e1dd
 git rev-list --count HEAD

466

vs

  git clone --branch=master https://github.com/astropy/astroquery.git astropy/astroquery
  cd astropy/astroquery
  git checkout -qf 32741121645692b3501b6da5137f4ae09064e1dd
  git rev-list --count HEAD

5074

[bsipocz]

I love to have a fix for the next astropy-helpers release for this that is agnostic to the depth of the clone. Ideas?

[bsipocz]

There is a way to switch it off on travis, that what I'll do with astroquery right now to fix our continuous deployment, but ideally we really need to find a solution for this.

[pllim]

Will this help? https://discuss.circleci.com/t/git-rev-list-head-count-gives-strange-results-on-circleci-server/654

[bsipocz]

Maybe. I postpone of finding a solution until we have a discussion on this first. Maybe most don't think it's an issue at all, or wouldn't mind non shallow cloning, with those the problem is easily solved. If that's not the case we need to fall back to one of the hack like in the link.

[astrofrog]

Another solution is to use the date of the latest commit instead of a sequential number, e.g. dev20181022103022

[pllim]

Is the date reliable with rebase?

[bsipocz]

good point. Also, if it becomes that long, then using the git hash would be unambiguous (though that probably won't work with pypi at all, but I haven't checked).