[Ecls-list] Question #1

[Tobias C. Rittweiler]

Gabriel Dos Reis <gdr at integrable-solutions.net>
writes:

> 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.

Notice that release numbers of actual releases won't change, just for
the in-between steps.

In fact, I think, EXT:+ECL-VERSION-NUMBER+ could just stay the same, but
an EXT:+ECL-COMMIT-REVISION+, or EXT:+ECL-COMMIT-ID+ should additionally
be provided.

I also think (lisp-implementation-version) should contain both in some
way, but I don't feel too strong about it. (It'll probably come handy
for Juanjo to be able to relate output in bug reports directly to a
commit, though.)

  -T.