Thoughts on adding git rev to dev version numbers?

[toddstrader]

How would everyone feel about adding git rev-parse --short HEAD to __version__? Currently it is 2.0.0.dev0 and I'm not sure what the final 0 is for, but I'm guessing it's to manually increment as one feels like? What if instead it were 2.0.0.dev-d379318e? I'd propose that we build the file on the fly in setup.py but only add the git rev when the non-suffixed version (stored as a variable in setup.py) includes dev.

I can take a stab at this if people are onboard.

[toddstrader]

In case it's not clear, the motivation for this would be to be able to determine what exact version of cocotb one is running when using non-released versions.

[ktbarrett]

setuptools-scm did this. But it did a lot more than that, poorly. Maybe you can extract the logic it uses from it. Technically I think the correct version we should be using is 2.0.devN, but I'd have to check the PEP. I'd like the N incremented for each commit as well. We could then just set the next release version in a Python variable and this would do the rest, rather than what setuptools-scm did just guessing the next version.

And ofc, this should be totally optional so people can still install release versions from source without needing more dependencies.

[marlonjames]

I would like this as well.

[toddstrader]

I should have known there was a PEP, there's always a PEP. It's PEP 440, but that says it's historical and points to this:
https://packaging.python.org/en/latest/specifications/version-specifiers/

Apparently devN is for developmental releases, not necessarily individual commits. Regardless, that's orthogonal to what I'm suggesting as just incrementing some number won't be unique across Git branches.

Also this:

DVCS based version labels
Many build tools integrate with distributed version control systems like Git and Mercurial in order to add an identifying hash to the version identifier. As hashes cannot be ordered reliably such versions are not permitted in the public version field.

As with semantic versioning, the public .devN suffix may be used to uniquely identify such releases for publication, while the original DVCS based label can be stored in the project metadata.

Identifying hash information may also be included in local version labels.

If I'm reading this correctly __version__ would look like 2.0.0.dev0+d379318e. Or something. But the rev would have to go after the +.

Also:

Local version identifiers SHOULD NOT be used when publishing upstream projects to a public index server

So is it fine to always add the git rev when there is a dev in the version? Do dev versions ever get published?