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

[Paul Eggert]

On 09/30/2016 01:54 PM, Robert Elz wrote:
> 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

Oh, perhaps I wasn't clear, as the current tz scheme does that too. That 
is, if you go back in time by typing 'git checkout 2016g' and then type 
'make', the automatically-generated version is simply '2016g' instead of 
a more-verbose version number generated for commits that are between one 
release and the next. The idea is to use Git's version-number generator 
rather than reinvent its wheel poorly.

> 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.

I agree that atomicity is a nicety and not an essential for us.

> All that is requied is that there be an easy way to extract the
> released versions from the repo

Currently, that's done with 'make version' which is a small front end 
for 'git describe'. It should be easy for developers who use a Git 
repository to run simple Git commands like that.

> assuming the redistributors will
> all use git and the git automated version stuff will make it happen is just
> naive.

Yes, we don't want to assume that. The current version-numbering system 
assumes either the traditional tarball download that contains a version 
number built for you, or a Git repository where you generate the version 
number.

> the only real equirement is that the location be fixed
> once and then not changed (just its value updated)

Yes, that's the main thing. We're not there yet, though.