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