John Peacock wrote:
> 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).
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?
> 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
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. This is important, because the version number on the tip of
the stable branch (branches/1.0.x in our case) must be different from
the one in the tagged release. That is, the creation of a release tag
from the stable branch should be followed immediately by a change to
svn_version.h. For example, in HEAD, the version numbers on the various
branches and tags would be (where N is the hghest released patch version):
Branch Version
/trunk 1.1.0-dev
/branches/1.0.x 1.0.(N+1)-dev
/tags/1.0.N 1.0.N
...
/tags/1.0.0 1.0.0
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.
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.
--
Brane Čibej <brane_at_xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jan 30 00:34:12 2004