Complete.Org: Mailing Lists: Archives: freeciv-dev: September 1999:
Re: [Freeciv-Dev] version numbers
Home

Re: [Freeciv-Dev] version numbers

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: rp@xxxxxxxxxx
Cc: freeciv-dev@xxxxxxxxxxx
Subject: Re: [Freeciv-Dev] version numbers
From: David Pfitzner <dwp@xxxxxxxxxxxxxx>
Date: Mon, 13 Sep 1999 13:44:25 +1000 (EST)

Reinier Post wrote:

> > Hmm, would this be the date when compiled, or when checked out,
> > of when last change checked in, or what?
> 
> When checked out.

Well, that doesn't sound very useful to me, but maybe I am 
misunderstanding, because below you mention using a crontab
on the server which seems more useful.

> > (Not to mention 
> > timezones...)
> 
> Using GMT or the CVS server's local timezone.
> 
> > This seems a bit complicated to me, especially 
> > having it work when using cvs to request old versions...
> 
> No, why?  It's a redefinition of the PATCH_VERSION #define
> that should be handled by a crontab entry on the CVS server.

As I mentioned before, you can't simply change PATCH_VERSION
because it is assumed in some places in the code to be integer
valued.  But one could do something using the VERSION_LABEL 
patch I posted, eg setting it to something like "-cvs-19990913".

However this still seems messy and non-trivial to me, because
of the number of places the version is defined (and eg have to
re-generate configure from configure.in), and due to possible
problems with cvs-developers overwriting or having conflicts
with the auto-updated file(s).  And what happens when one
wants to release a stable version, accessible from a CVS tag?
Never mind if we ever want to use CVS branches...

Even the date may not tell you enough, because you could still 
have two incompatible versions with the same datestamp.  A 
global counter which is updated every check-in might work, but 
would be painful in other ways and even more prone to causing 
problems for cvs-developers.

I think:

1. If we mark the version as eg "-cvs", and have the metaserver
show that, that should help in the short term.  People using or
connecting to cvs versions should be prepared to tolerate some 
(hopefully minimal) surprises.

2. Ultimately, compatability is and should be indicated by the
capability string.  This is informative, under direct developer
control, has no hassles with CVS (and branches etc), and has some
chance of working in the case that someone has applied some 
random patch which changes the capability.

-- David

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