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: jdorje@xxxxxxxxxxxxxxxxxxxxx
Cc: freeciv-dev@xxxxxxxxxxx
Subject: [Freeciv-Dev] Re: (PR#2479) Change version string of development versions
From: Raimar Falke <rf13@xxxxxxxxxxxxxxxxx>
Date: Thu, 30 Jan 2003 18:02:35 +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.
> >>
> >>Reinier: is this possible? How much work required?
> >
> >
> >It is simple - so simple that I think we can actually rely on its
> >correct operation.  But I'm not going to publish the details on RT.
> >
> >This is a better as it allows shorter version numbers.  Its version
> >number would always be x.y where y is autoincremented by every commit.
> >And x can be kept identical to the Freeciv patch version number.
> >That way a full version can be generated out of it (1.14.1.3766)
> >that uniquely identifies the contents of the code base.  That would
> >be very useful.
> >
> >The only technical question is whether multi-file commits should be
> >treated as a single one.  (We have looked at this before but I'm not
> >sure what the best answer is.  Some clients produce sequences of commits
> >on individual files but with the same log message that lists all of them.)
> 
> Excellent.  I am all in favor of this.
> 
> BTW: it should be 1.14.99, not 1.14.1.

> Rather than have the file contain '#define MASTER_REVISION="3766"' I 
> think it should just contain '3766'.  We can then do something like

No. It will contain the revision in a way that cvs can update it:
$Id$.

>   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).

There is no configure involved. That would require that you run
configure after each update. No the content of the master file will
only be used by version.c to build the correct label.

> 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.)

It is easy to do the mapping master revision -> date.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 "The two rules for success in life are:
  1) Never tell them everything you know."



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