upgrade versioneer

[zooko]

We copied versioneer into pycryptopp a while back, and Brian has ​updated versioneer since then. It would be nice to use his latest stable release. There are, however, a couple of behaviors we require from versioneer that upstream versioneer might not support without being patched. One is, we put the git commit into the version number: [d3798e2d1ed1bc537e52c3cb21aac52a95235504/git], [f68d4790502acc7324b4e6c6b6d8ead95bfa78be/git]. The other is: we write the version number into a .h and/or .cpp file: setup.py​. So if we update the version of versioneer we bundle, we would probably need to patch it (again) to make it do those two things.

[daira]

I'm unconvinced that putting the git commit hash in the version number was a good idea.

[nejucomo]

I like having the commit hash in the version from the standpoint of "coolness". The purported advantage is that no two releases from different revisions will have colliding versions. Also, it is theoretically possible to find the git revision starting from the package version.

It does present a problem for making frequent releases and using a tool like pip to install those releases, because version comparison means the least significant releases may have a "smaller" version than releases from older revisions.

A funny idea is to put a file with random entropy, or add entropy to the commit comment, such that the integer encoding of the git revision increases with every micro commit. A commit hook would repeatedly generate commits until the version number increases, at the expensive of fossil fuels and sanity.

[nejucomo]

If pycryptopp plans to do "micro releases" such as pushing to PyPI very frequently, it would be best to use a ​PEP 0440 "development release" tag in the version.

The reason is that as of 1.4rc2 (or possibly prior, but not as early as 1.3.1), pip will *not* upgrade to "development releases" unless the user requests it with the --pre flag to pip install. The thinking is that users will be able to decide if they want to follow "stable releases" or "development releases".

So, in that scheme, the pycryptopp version should look like 0.6.0.post1206569328141510525648634803928199668821045408958 instead of 0.6.0.1206569328141510525648634803928199668821045408958.

Even without the silly hash-collision scheme above to improve the ordering, appending git hashes to only dev releases will help ensure "stable releases" are monotonically increasing.

[zooko]

Replying to nejucomo:

It does present a problem for making frequent releases and using a tool like pip to install those releases, because version comparison means the least significant releases may have a "smaller" version than releases from older revisions.

I don't think this is a problem for programs like pycryptopp which use versioneer, because versioneer already provides a way to have monotonically increasing versions.

In the git-hash-hack, git hash is appended to the least-significant end of the version number. That is, let X represent the version number that we generate without the git hash hack. Then, the version number that we generate with the git hash hack is X ⊗ hash, where "⊗" means concatenation. Therefore, if the ordering of versions-with-git-hash-hack would suffer from the problem that you describe, this implies that the versions-without-git-hash-hack would collide.

So, whatever method that versioneer uses to generate increasing version numbers, such as a monotonically increasing "post-release-number" like nejucomo suggests in the comments here, or using the count of commits in git, or the height of the Bitcoin blockchain, or whatever, then when you append the git-hash-hack to that, and you can never have the problem that you describe, in which the contents of the git-hash determine the sort order.

Am I missing anything?

[gdt]

A few separate thoughts:

• if there is any significant desire to install other than real releases, that's a clue that releases need to be more frequent. If we're only talking about people doing development who want an easy way to upgrade many boxes, that's something else.
• the rc, pre, post, etc. names have gotten out of control. packaging systems have to cope with each new flavor. There really needs to be a single standard published and agreed on (by freedesktop perhaps?). Personally I am a fan of the old-school GNU versioning scheme from the early 90s with numbers only, where 1.7.80 is an alpha release towards .8, and 1.7.90 is a beta release. Things that are after a release but not heading to a future release are just not releases and don't get numbers!
• git revisions are not version numbers. They shouldn't be used in version numbers as if they had the necessary properties. They are great to put in a .h etc. to be able to know where the bits came from, which is different.
• git has a mechanism for this already; do git describe --tags, and if necessary make tags a bit more judiciously to make this come out right. But git's describe output isn't really right for versions, because it has dashes and tag names and that won't compare lexicographically (you have to figure out what is a number). But the middle number is useful. Therefore, do N.M.80.G, where N.M is the old version, 80 means "alpha that isn't really alpha", and G is the count of commits that are in the snapshot that weren't in N.M.
• playing games with hashes to make them sort is ridiculous. It's putting crud in the source tree to make something that should not be expected to have a property have that property. It's a neat hack to show that you can do it (reinventing hashcash :-), but I don't think it should be used.

[davidsarah]

I am absolutely not a fan of pycryptopp 0.6.whatever's ridiculously long version number. Version numbers are expected to be human-meaningful and global, therefore by Zooko's triangle (and absent a Namecoin-like infrastructure which we can't rely on yet), they can't be securely unambiguous.

[zooko]

I don't want to stop using the git-hash-in-version-number hack.

In any case, this ticket is not about that! This ticket is about upgrading to the latest version of Versioneer without changing the current functionality. It is not about whether to include the git hash in the version (comment:1 and many other comments), or otherwise changing the version numbering scheme (comment:5).