Dan Harkless wrote:
>
> Dan Winship <[EMAIL PROTECTED]> writes:
> > How about we [insert some magic here that I haven't had time to think
> > about in depth] so that non-release builds get the date (YYYYMMDD)
> > appended to the version number. So you know _exactly_ what level of
> > bugfixiness they have in their clients.
>
> Sounds good to me if it's doable, assuming the YYYYMMDD you're talking about
> is the date of check-in of the newest file amongst those you're compiling
> (presumably including non-compiled files like scan.man).
The easiest way of doing this that comes to mind is to play with some
magic in configure.in. Up until 1.0.3 is released, we have "1.0.2" in
the VERSION file. When we're ready to tag the tree as 1.0.3, we put
"1.0.3-REL" in the VERSION file, then as soon as the CVS tree is tagged
it gets changed to "1.0.3". In configure.in, when $VERSION is being
built we can check for the "-REL" - if it's there we strip it, otherwise
we add the current date to $VERSION. Something like (untested):
VERSION=`sed -e 's/nmh-//' ${srcdir}/VERSION`
case $VERSION)
*-REL)
VERSION=`echo $VERSION | sed -e 's/-REL//'`
;;
*)
VERSION=$VERSION-`date +"%Y%m%d"`
;;
echo "configuring for nmh-$VERSION"
This is a little convoluted, but keeps the contents of the VERSION file
simple and doesn't rely on commits having to keep other files up to
date.
Do all versions of Unix support "date +<format-string>" - maybe we'd
need a little script or C program to create the date in the format we
want.
Simon.
