make TAGS for releases to pypi

[adriaanph]

please create a TAG with the version number whenever you push a new release to pypi.org

[jacopoantonello]

Currently a new release is automatically created and pushed to pypi every time commits are added to master. The version number is also automatically incremented. So I wasn't planning to create tags here. This saves me time as I don't have to do anything besides committing to master (GitHub uploads to pypi itself). Does this create issues on your side?

[adriaanph]

no, it doesn't create any issues as such, it's just for traceability. for example, when i encoutered the "version=0.0.0" issue #11 i wanted to browse the github repository at the revision that corresponds with the package in pypi. however, because i couldn't find any TAGS i had to go on a hunt.

[adriaanph]

i have just seen that you do in fact create tags, but they are "informal TAGS" rather than "annotated TAGS". i suspect that simply using "annotated TAGS" should resolve both issues #11 & #12.

informal TAGS are listed by git describe, currently:
v0.0-30-g39e5902

annotated TAGS are listed by git tag, currently:
v0.0

according to the git reference

Annotated tags are meant for release while lightweight tags are meant for private or temporary object labels.

[jacopoantonello]

I only created one annotated tag v0.0. I did use the informal tags in the past but they are not compatible with PyPI as far as I could tell, so I disabled them. I plan only to add another annotated tag if something major changes in the future.

setup.py automatically generates a version from the v0.0 tag every time new commits are added to master. And it automatically publishes the package to PyPI. So I don't have to do that manually. You can still have some traceability

import zernike
print(zernike.__commit__)

This is not best practice. But for now I'd rather keep this simple system unless there are major inconveniences with it.

[adriaanph]

i have no reason to keep pushing this point, this is your prerogative.