[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: Branko Čibej <brane_at_xbc.nu>
Date: 2004-01-30 08:24:52 CET

John Peacock wrote:

> Branko Čibej wrote:
>> 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?

The Win32 build doesnt "need" 4, it's just that Windows _provides_ 4
components, and these are visible to the user via the file properties
dialogue in Explorer. I don't think there's a convention about using the
4th number (even Microsoft's components arent consistent in their
usage). Currently the Win32 build puts '0' there for development
versions, and the revision number of the release (whatever _that_ means)
for official builds.

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

We can't suppress the 4th number from the Windows file props dialogue.
That's why I currently put a (marginally meaningful) number there,
although that has it's problems because we're limited to 2^64 revision

We'd never show the 4th number in SVN output or tarball names, of course.

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

We don't need a range for -dev, because we won't make official
development snapshots -- once the code is stable enough to make a
snapshot worthwile, it's either alpha or beta.

> It still requires some preprocessor magic to render the output, but
> not too difficult.

Actually, it turns out it requires more than just preprocessor magic...

#define SVN_VER_STATE 103 /* Let's call this alpha3 */
# define SVN_VER_TAG "-dev"
#elif SVN_VER_STATE > 300
# define SVN_VER_TAG ""
#elif SVN_VER_STATE > 200
# define SVN_VER_TAG "-beta" FIX_NUMBER(SVN_VER_STATE - 200)

Bam! There's no way I know of to implement FIX_NUMBER in the C
preprocessor so that it yields string representations of numbers from 1
to 100. The last thing I want is nine zillion #if/#elif pairs, one for
each value of SVN_VER_STATE.

We have to think of something else, sigh...

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 08:25:06 2004

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.