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

[Robert Elz]

    Date:        Fri, 30 Sep 2016 10:35:03 -0700
    From:        Paul Eggert <eggert at cs.ucla.edu>
    Message-ID:  <08763380-238a-9dc8-3058-3e564a33738c at cs.ucla.edu>

  | This is what we've always done for the tz project.

For the vast majority of the life of the tz project, the repository wasn't
available, so "always done" really means just the last few years...

And in any case, the repository is constantly changing (if I recall the
sequence of events, and I know this was an unusual case) for 2016g the
repository had already been updated before the official tarballs were in
place - "so the compare and see local mods" was never going to work there,
and cannot really be expected to work in normal circumstances - anyone
who needs to do this needs their own repo (NetBSD does this - for the data
we make no local changes, so it doesn't add much, but the code is different)
or at least to keep (or fetch again) a virgin distribution copy they can
compare against.

The way NetBSD handles the "version in the repo" problem is to update
the repo to the desired version string when a new version is branched
(for tz that means released, as we have no updates to released versions,
just new ones) and then immediately after the release tarballs are made,
update it again (given branches, one branch not says, the equivalent of,
"2016g + patches", and the other "development for 2016h".)   For the
simpler distribution policies of the tz project, there just "2016g+" or
something in the repo, immediately after the tarballs are made would be
fine (and informs people that what they're seein from the repo is everything
that was in 2016g, plus later patches - initially just that one single
patch for the vesion string of course - and that 2016h is not available yet.)

  | You're right that we could go the other way and distribute files that 
  | purposely differ from what's in the repository. However, I suspect this 
  | would cause more trouble than it cures, in the long run.

I doubt it, as in practice, after a few days anyway, that is what happens.
Of course, whatever is distributed should be available from the repo with
suitable extraction parameters (requesting a specific version - I don't know
git well enough to know what the terminology is there) - that is, the new
version string should be checked in, the release made, and then an update
checked in immediately after - not just extract the files from the repo,
edit one, and then ship that.

kre

ps: for tzdata NetBSD manually (currently) tracks the version info (we have
not always updated to every new version,) so we know which we have, and which 
is current - and so which tarballs we should fetch - that allows us to use
the version labelled tarballs, rather than "latest" - so the version info
that's in there, now that there is some, somewhere, is just ignored - we
make use of the info before we have fetched it.  Once it seems likely that
the way the version is represented inside the tarballs becomes stable, we
will (or at least I intend) that we will check what we're expecting to get
with what we fetched claims to be as one more validation step.

For tzcode we don't much care what the version's label is, NetBSD's code base
is different enough (though must of it is based upon the reference impl,
originally) that claiming we're on 2016g code would be a misrepresentation.
The code gets updated mch less frequently than the data (it is considerably
more work to merge) which is one reason I am not much a fan of the combined
tarball approach - mostly the code is just trash to discard.)