When we tag a new release two CI builds are kicked off - one for the fact that there is a new commit on master, one for the fact that a new tag build is stated. Sometimes the git clone for the master builds will occur after the tag is placed, and so versioneer still reports the build as a tag. This can be seen here:
https://travis-ci.org/menpo/menpofit/jobs/131907583
We currently don't force the upload of release binaries, which leads to a failure.
It would be better if we had a strategy for such cases. One such strategy would be to add a --force flag to the upload, so existing releases are replaced without complaint. I didn't do this initially as it opens the door to worrying bugs if something goes haywire...maybe there is a better solution? @patricksnape thoughts?
When we tag a new release two CI builds are kicked off - one for the fact that there is a new commit on master, one for the fact that a new tag build is stated. Sometimes the git clone for the master builds will occur after the tag is placed, and so versioneer still reports the build as a tag. This can be seen here:
https://travis-ci.org/menpo/menpofit/jobs/131907583
We currently don't force the upload of release binaries, which leads to a failure.
It would be better if we had a strategy for such cases. One such strategy would be to add a
--forceflag to the upload, so existing releases are replaced without complaint. I didn't do this initially as it opens the door to worrying bugs if something goes haywire...maybe there is a better solution? @patricksnape thoughts?