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], [bug-gnu...@gnu.org]) >>> >>> 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 (g...@gnu.org)
PGP.sig
Description: This is a digitally signed message part
