Date: Fri, 30 Sep 2016 13:06:25 -0700 From: Paul Eggert <eggert@cs.ucla.edu> Message-ID: <631e15b0-31dd-be7f-36ec-1da444456075@cs.ucla.edu> | 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. You obviously don't have to do that ("2016g+") if you don't want, a new version string for every commit is just fine (though personally I find the git auto-generated version strings obnoxious - not that I have any better scheme for auto generated versions) - the point was to explicitly set the version string to the release identifier (overriding any auto generated version) to make the release tarballs and then set it back to indicate a development version immediately after that (watever that version string looks like, and however frequently it changes - for netbsd while we don't change the "2016g+patches" type version ID (any patches there are reqired to keep compat, so all you ever get is bug fixes) but the "on the way to 2016h" type version ID is updated as required, that one is not constant. I don't think it matters (especially here where there are not hundreds of actual committers) whether the release generation is in any sense atomic. It is all going to happen with one "make tarballs" or whatever, whether that runs one git command, or a dozen, really doesn't matter (the only significant cost is that of safely generating the signatures while protecting the private key). All that is requied is that there be an easy way to extract the released versions from the repo (and possibly/probably less easy ways to extract the intermediate versions should that ever be needed, and any repo software & scheme, managed rationally, should allow all of that.) Also, nothing that you can do (possibly excepting just asking "please don't do that") can possibly solve the problem of redistributors changing the data without changing the version string - assuming the redistributors will all use git and the git automated version stuff will make it happen is just naive. The signatures allow people who actually see the tarballs to know whether they have the original versions or not, but for all those who just get the binary files installed, there's nothing rational to be done (we could generate and distribute them, and sign each one, but that only works if we somehow convince the implementations to actually verify the signatures - and the overhead of that, for everyone, would be absurd.) kre