ATM, the version is just appending the number of steps after the tag, which does not distinguish between branches, so it is quite useless with respect to the extensive heavy machinery of versioneer... :chipmunk:
proposed solution
it redo versions and add the workflow for automated releasing
Redo version relies on a static file instead of git, which allows installation with git archive as, for example, pip install https://github.com/python-cachier/cachier/archive/refs/heads/release-version.zip
The generated package that would be uploaded to PyPI has only this static version, as expected. :rabbit:
For development and using pip install -e . (which relies on the living code as -e does only symlink to the local source code), it will append actual sha so instead of the 2.2.2.post.dev25 gives v2.3.0.dev+c16f0f1 which is easier to identify what version is really used/running... :robot:
resolves #158
Actual state
ATM, the version is just appending the number of steps after the tag, which does not distinguish between branches, so it is quite useless with respect to the extensive heavy machinery of
versioneer
... :chipmunk:proposed solution
it redo versions and add the workflow for automated releasing
Redo version relies on a static file instead of git, which allows installation with git archive as, for example,
pip install https://github.com/python-cachier/cachier/archive/refs/heads/release-version.zip
The generated package that would be uploaded to PyPI has only this static version, as expected. :rabbit: For development and usingpip install -e .
(which relies on the living code as-e
does only symlink to the local source code), it will append actual sha so instead of the2.2.2.post.dev25
givesv2.3.0.dev+c16f0f1
which is easier to identify what version is really used/running... :robot:For release, the process is such:
cachier/version.info
summary
v2.3.0
v2.3.0.dev0
v2.3.0.dev+e681025