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.<div><br></div><div>I see some problems with this. One is that the release number is stored now in configure, <a href="http://configure.in">configure.in</a> 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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>Juanjo<br clear="all"><br>-- <br>Instituto de Física Fundamental, CSIC<br>c/ Serrano, 113b, Madrid 28006 (Spain) <br><a href="http://juanjose.garciaripoll.googlepages.com">http://juanjose.garciaripoll.googlepages.com</a><br>

</div>