Re: installable gnulib library

[Gary V. Vaughan]

Hi Bruce,

On 11 Oct 2010, at 12:06, Bruce Korb wrote:
>>> Of course it is.  To properly understand 150+ lines of usage text
>>> one needs to read the source and understand the intimate details
>>> of libtool and autoconf.  I keep meaning to, but life gets in the way.
>> 
>> Are you implying that libtool is complicated? ;)
> 
> Not at all.  It is, but I was saying that gnulib-tool is complicated:
> $ ./gnulib-tool --help|wc -l
> 158

I was kidding! Libtool certainly *is* complicated :)

>>>> AC_INIT([libposix], [20101010], address@hidden)
>>> 
>>> The version will need to be computed :)
>> 
>> Did I get the calculation wrong?  I am UTC+8, so it was right for me at the
>> time I wrote it ;)
> 
> No.  But is is wrong now.

Nah.  That's still the 20101010 version, even today.

> Besides, we've already made the (reasonable)
> agreement that the version number is based upon the first date found
> in the ChangeLog.  If the ChangeLog changes, the version has to change.
> It has to be scripted.

Well, that's not a terrible heuristic... but it will mean the version number
can bump when someone commits a change to a non-libposix module.  I think
we might as well use git-version-gen, and use a conventional release number
whenever rolling a new release tarball.

>> But seriously, gnulib already provides the tools to do this (git-version-gen
>> and .tarball-verion), so let's use the existing rather than invent something
>> new.
> 
> There is no script name "tarball-version", so I don't know what that is.

.tarball-version holds a snapshot of the version number in a tarball release
so that git-version-gen can either pull a version out of git if it is run
inside a cloned git tree, or else fall back to the .tarball-version number.

> The reason for the date version is to make it easy for client projects
> to say, "I know that what I need was added by October 10, 2010, so the
> libposix version must be more recent than 20101010 -- though I would really
> prefer to spell it 2010.10.10 because it is so much easier to read and
> it is compatible with the syntax version parsers are expecting.

Hmm... this is what I didn't like about gnulib non-releases... "I know the
feature I wanted was introduced on 2010.10.10, so I'll use some random
version of libposix newer than that.  Maybe it won't have introduced a
bunch of new buggy code compared to some other random post-2010.10.10
release tarball."

I'm not entirely against date based versions, but since determining relative
stability of a release involves git and mailing-list archaeology anyway, I
really don't see terribly much advantage over a traditional release number.

Cheers,
-- 
Gary V. Vaughan (address@hidden)

PGP.sig
Description: This is a digitally signed message part