On 09/30/2016 12:38 PM, Robert Elz wrote:
For the simpler distribution policies of the tz project, there just "2016g+" or something in the repo, immediately after the tarballs are made
Although that's better than the pre-2016g tz versioning scheme, it's worse than the current scheme because it would use the same version number "2016g+" for every commit between 2016g and the next release. In contrast, the current tz versioning scheme updates the version number automatically with every commit, and this is more precise. For example, in the current development repository (commit 63207b74698aa9642f9c17f635c65b0114c6d191) the version number is 2016g-11-g63207b7, whereas in the previous commit the version number is 2016g-10-g373261b. In larger projects there may be reasons to use less-precise version numbers, as this avoids rebuilding everything that depends on the version number merely because some otherwise-unrelated component changes. Also there's some inertia, as older projects (such as CPython, mentioned by Alexander Belopolsky in this thread) developed their versioning schemes with repository software that didn't support automatic version-number generation as well as Git does. The tz project is small, though, and we don't have to worry about SCCS compatibility any more, so neither of these issues are significant for us.