[Ecls-list] Question #1

[Gabriel Dos Reis]

On Mon, Feb 15, 2010 at 2:23 PM, Juan Jose Garcia-Ripoll
<juanjose.garciaripoll at googlemail.com> wrote:
> 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.
> Juanjo

I can understand the idea behind a finer grained release number.
However, I think that a release number should be simple enough
(e.g. current scheme) and should refrain from dumping the
internals of whatever SCM is used to produce a release.

On the other hand, I'm fine with tagging development sources
in whatever ways, as long as it does not get into the release identification.