Branko Čibej wrote:
> The way I understand it, you're advocating using only numbers so that
> it's easier to write tools that will sort the version numbers correctly,
> right?
That's one reason. The other is that it is much harder to mess up incrementing
a number than it is to edit text consistently. I'm much happier if I can write
my user-visible output once and just let the machine work it out after I
increment the appropriate values.
And just to make it clear, I was never advocating that the negative component
would ever be visible except in the include file. All external representations
of the version would come from the preprocessed/human readable form (including
tags in the repository). The negative version components are just a means to an
end, nothing more.
>
>
> Since you're starting with a negative patch version, this means you have
> no way to represent prerelease versions of patch releases, e.g.,
> 1.0.1-dev.
I hadn't thought of that contingency. Hmmm...think...think...
> I'd also like to address the issue of version numbers embedded in the
> executables on Windows. Win32 uses a version number with four
> components; however, they're all positive numbers, so your scheme can't
> be easily translated to the Windows one.
Also something I was not aware of. Why does the Win32 build need 4?
>
> How about leaving the patch number alone, and using the fourth component
> to indicate the status:
>
> Value Meaning
> 0 -dev
> 1..100 -alpha1..100
> 101..200 -beta1..100
> 200..300 -rc1..100
> 301.. released
>
> This way we can even use the revision number of the release for final
> releases. :-) And we still keep the ascending sort order.
>
That's OK, I guess (though I hate to build any limit into the number of
intermediate values). And why would we have any value for the fourth component
on a released version? I would rather reserve 0 for that state (so the #if can
suppress it from view).
How about this:
Value Meaning
0 released
1..500 -dev
501..800 -alpha1..300
801..900 -beta1..100
901..999 -rc1..99
since we are likely to spend much more time at a -dev or -alpha status than
-beta or -rc. It still requires some preprocessor magic to render the output,
but not too difficult.
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4720 Boston Way
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5747
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jan 30 04:50:16 2004