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 17:25:37 +0100

On Wed, Jan 29, 2003 at 08:10:17AM -0800, Raimar Falke via RT wrote:
> On Tue, Jan 28, 2003 at 11:42:54PM -0800, Jason Short via RT wrote:
> > 
> > [rfalke - Tue Dec  3 08:01:57 2002]:
> > 
> > > Development version should use a string of the format "CVS <date>"
> > > where <date> is in ISO date like 2002-12-03 instead of the current
> > > "1.14.1-devel". The date should be the build date.

This has a serious problem: a date doesn't identify the contents of
the repository.  Better use a timestamp in seconds.

A less serious problem: I don't like the format chosen.
Software versions should be numbers separated by dots so as to be be
comparable numerically.  So I'd rather see 1.14.1.20021203 (and
a much longer number to identify a particular second of the day
is even better).
 
> 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.)

>       Raimar

-- 
Reinier


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