[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: implementing version numbering

From: John Peacock <jpeacock_at_rowman.com>
Date: 2004-01-29 23:03:34 CET

Branko Čibej <brane@xbc.nu> writes:
>I don't understand why you'd want to introduce a fourth level of version
>numbers. We use SVN_VER_TAG (and SVN_VER_NUMTAG) to mark prereleases.
>Here's how svn_version.h would look like on trunk after 1.0:

I think that each of the elements of a version should contain only numbers
(internally), so that it is very obvious (if not rote) to know exactly what
needs to change for each release. It also nicely handles the fact that the
alpha, beta, rc releases are more closely related to the upcoming final version
than they are to the previous releases. You need a fourth term because you are
now tracking 4 things (the additional being whether you are talking about alpha,
beta, or release candidate).

You only need to look at the current version, 0.37.0, to see that it does not
hint that this might be the same code as 1.0.0. In essence, 0.37.0 is really
1.0.0 minus some small value. That's why in my second e-mail, I used these

     0.33.0 => 1.0.-2.0 => 1.0.0-beta0
     0.33.1 => 1.0.-2.1 => 1.0.0-beta1
     0.34.0 => 1.0.-2.2 => 1.0.0-beta2
     0.35.0 => 1.0.-2.3 => 1.0.0-beta3
     0.35.1 => 1.0.-2.4 => 1.0.0-beta4
     0.36.0 => 1.0.-2.5 => 1.0.0-beta5
     0.37.0 => 1.0.-1.0 => 1.0.0-RC0

Whatever the software displays to the user (the third column above), the
internal #defines are just numbers, and they change in easily automated ways.
I've been working on version objects in Perl for more than two years, and my own
version::AlphaBeta module does exactly this, so that the external representation
makes sense to humans, yet the internal representation is trivial for a machine
to perform either comparisons or to increment.


John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD  20706
301-459-3366 x.5010
fax 301-429-5748
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jan 29 23:03:30 2004

This is an archived mail posted to the Subversion Dev mailing list.