Complete.Org: Mailing Lists: Archives: freeciv-dev: January 2003:
[Freeciv-Dev] Re: (PR#2479) Change version string of development version
Home

[Freeciv-Dev] Re: (PR#2479) Change version string of development version

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: freeciv-dev@xxxxxxxxxxx
Subject: [Freeciv-Dev] Re: (PR#2479) Change version string of development versions
From: Reinier Post <rp@xxxxxxxxxx>
Date: Thu, 30 Jan 2003 18:13:40 +0100

On Thu, Jan 30, 2003 at 11:34:18AM -0500, Jason Dorje Short wrote:
> Reinier Post wrote:
> >On Wed, Jan 29, 2003 at 08:10:17AM -0800, Raimar Falke via RT wrote:
> 
> >>Another alternative would be to have a file which is committed
> >>after/with every normal commit. This file contains something like:
> >>
> >>#define MASTER_REVISION="$Id 1.45$"
> >>
> >>and at runtime we build a version string ("1.14.1-45" for example)
> >>from this.

[...]

> Excellent.  I am all in favor of this.
> 
> BTW: it should be 1.14.99, not 1.14.1.

Why?  What does 99 mean except that it reminds us of the Linux kernel?

> Rather than have the file contain '#define MASTER_REVISION="3766"' I
> think it should just contain '3766'.  We can then do something like
> 
>   VERSION_LABEL=`cat master_revision`
> 
> in configure.ac.  OTOH this may make the version.h bits harder (if they 
> can't rely on the master revision value and AC_SUBST is not possible).

It will more often work to derive the version number from the $Id$
string at runtime.

> One question: how useful will the version number be?  Would it be more 
> useful to have a date, that could be used for cvs up -D?  (The date 
> would be that of the CVS repository right after the most recent commit.)

That is unreliable although it would work 99.9% of the time.

> jason

-- 
Reinier


[Prev in Thread] Current Thread [Next in Thread]