Re: implementing version numbering

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
examples:

     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

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