It has been suggested to me that I should use a version number with a finer granularity than the current release code, ideally increasing with _every_ commit.
I see some problems with this. One is that the release number is stored now in configure, configure.in
and msvc/Makefile, so every increase implies changing three files. This could be solved by creating a fourth file, VERSION, in src/util or somewhere, which stores the last decimal in the release number and which should be updated with every commit and emptied for releases.
The other problem is that maintaining this additional file implies quite some additional work and control on my side. I tried this before and did not succeed. An alternative is having hooks in .git that automatically upgrade the file, but so far I have been unable to achieve this: the hooks are run before commits, indeed, but they can not change the list of files that are committed.
A final, perhaps better solution, would be to test for the existence of both the .git directory and the "git" program itself and encode the last commit date in a final version number. This would mean that users of releases or CVS would not get to see those extra release numbers.