Simon Burge <[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.
Well, the date you configure the package may have nothing to do with the
date it was pulled off of CVS (or the date the most recently checked-in file
was checked in prior to you doing so).
If the appended date is going to be as arbitrary as the date nmh was
configured, I'd probably prefer something simpler like an appended '+'.
The -version option already tells you the date you compiled nmh, which will
generally be the same date you configured it.
-----------------------------------------------------------------------
Dan Harkless | To prevent SPAM contamination, please
[EMAIL PROTECTED] | do not post this private email address
SpeedGate Communications, Inc. | to the USENET or WWW. Thank you.
