[tz] Are tzdata2016g & tzdata-latest missing the VERSION file?
eggert at cs.ucla.edu
Fri Sep 30 22:14:52 UTC 2016
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
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
> 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.
More information about the tz