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

[Reinier Post <rp@xxxxxxxxxx>]

On Wed, Jan 29, 2003 at 09:00:46AM -0800, Jason Short via RT wrote:
> 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.
> > 
> > 
> > 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.
> 
> This *sounds* like a great idea.
> 
> But first of all I don't know how/if it is possible.

It is.
 
> Secondly, it will require a commit to this file every time any other 
> file is committed.  This may be done by a script, but having a script 
> that actually makes changes to the code is dangerous.

Sure but the script is simple.  We already have a script that runs
cvs up - one that runs cvs ci on a single file isn't all that different.
(Well OK - it must take care to eliminate recursion.)

> Thirdly, it won't actually give foolproof results.  If you "cvs up -A" 
> or "cvs up -D ..." from the toplevel directory, you're fine.  But if you 
> apply a patch or update only part of a repository, your datestamp will 
> be misleading.  So the end result is that it will work for the daily 
> snapshots, but not too well for any self-compiled CVS versions.

I don't understand your argument.
The scope of a commit doesn't matter: the script will always be invoked.

If you're going to assign a version number it might as well be chosen to
completely identify a particular state of the code base.  A date doesn't
do that.  A timestamp in seconds doesn't even do that (multiple commits
within the same second do happen).  This mechanism does.

> That said, the alternative I proposed doesn't seem that great either; it 
> also works just fine for the daily snapshots but even worse for 
> everything else.

It only "works fine" for snapshots to the extent that it identifies
the snapshots relative to each other.  It doesn't allow you to
identify the snapshots with a particular state of the code base.

> The goal is to know what code someone is using when they report a bug. 
> So perhaps the daily snapshots could have their version manually changed 
> to "CVS-2003-1-29".  This way we get the CVS tag on them but not on any 
> manually-generated snapshots.  So from normal users we get a good 
> datestamp but from those compiling from CVS we get just get "1.14.99" 
> and we know they're using CVS directly.

There is no need to adopt such a useless solution
when a perfect one is just as easy to implement.

> jason

-- 
Reinier