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.