[tz] Are tzdata2016g & tzdata-latest missing the VERSION file?

[Robert Elz]

    Date:        Fri, 30 Sep 2016 13:06:25 -0700
    From:        Paul Eggert <eggert at cs.ucla.edu>
    Message-ID:  <631e15b0-31dd-be7f-36ec-1da444456075 at 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