[Ecls-list] Question #1

[Gabriel Dos Reis]

On Mon, Feb 15, 2010 at 3:27 PM, Tobias C. Rittweiler <tcr at freebits.de> wrote:
> 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.

that would be fine with me.

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

I would prefer a separate interface to report the commit version, and keep
the current format for (lisp-implementation-version),

-- Gaby