Closed chmreid closed 4 years ago
The Makefile already has a hca/version.py
rule that updates hca/version.py
using the version number in setup.py
. That rule should be added to the release process, in addition to documenting this info somewhere.
I raised an issue about version numbering previously (see #475 and associated PR #476, then PR #484 to revert #476). The original problem was that the version number in
hca/version.py
was not consistent with the version number insetup.py
, which makes it very confusing to figure out what version of thehca
command line tool one is using.With the latest version 7.0.0 that was released, this is a problem again, as
setup.py
specifies version 7.x whilehca/version.py
specifies an older release (6.x). The underlying issue that's causing inconsistent version numbers still has not been addressed. Whatever logic is being used (which version numbers are updated, which ones are correct) has not been documented. The release procedure does not automatically bump the version number, and there are no instructions for manually changing the version number.There is also no documentation that specifies what the version number "0.0.0" refers to (per discussion in the two PRs linked to above, it means this is a development version) or whether developers should specify the version number as "1.2.3dev" or as "0.0.0". Further confusing the issue is whether developers should update the version number in
setup.py
or inhca/version.py
or both.Furthermore, because
hca/cli.py
(https://github.com/HumanCellAtlas/dcp-cli/blob/master/hca/cli.py#L54-L74) uses the version number inhca/version.py
to check if the HCA tool version number matches the latest from PyPi, thischeck_if_release_is_current()
function will always give an incorrect answer if the setup.py and version.py version numbers are different.Fortunately it should be straightforward to solve this issue: decide on a convention and document it somewhere, then make the versions consistent with the convention again.