[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: installable gnulib library
From: |
Gary V. Vaughan |
Subject: |
Re: installable gnulib library |
Date: |
Mon, 11 Oct 2010 13:25:23 +0700 |
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
- Re: installable gnulib library, (continued)
- Re: installable gnulib library, Gary V. Vaughan, 2010/10/10
- Re: installable gnulib library, Gary V. Vaughan, 2010/10/10
- Re: installable gnulib library, Gary V. Vaughan, 2010/10/10
- Re: installable gnulib library, Eric Blake, 2010/10/11
- Re: installable gnulib library, Bruce Korb, 2010/10/10
- Re: dprintf, fprintf memory leak, Bruno Haible, 2010/10/10
- Re: installable gnulib library, Gary V. Vaughan, 2010/10/10
- Re: installable gnulib library, Bruce Korb, 2010/10/11
- Re: installable gnulib library,
Gary V. Vaughan <=
- Re: installable gnulib library, Gary V. Vaughan, 2010/10/09
Re: installable gnulib library, Bruce Korb, 2010/10/10