Simon Burge <simonb@netbsd.org> writes:
> > (2) i think you do need to cope with the _ALPHA and _BETA issue.
> 
> I had a think about this and couldn't come up with anything.  Parsing
> __NetBSD_Version__ and then looking for ALPHA, BETA, whatever crossed my
> mind, but I thought it'd be better to do it either one way or the other.
> Unfortunately I didn't come up with a representation that fits the
> current setup.
> 
> Hmm, maybe we can use those two `0's at the end - how does:
> 
> 	MMmmrrppRl
> 
> sound, where 'R' is 0 for pre-release and '1' for released, and 'l'
> is the level - '0' for alpha, '1' for beta, and so on.  This still
> satifies 1.4 (104000010) > 1.4BETA (104000002).

this seems reasonable to me.


> You could even
> encode a released 1.4.2B and an 1.4.2B_BETA this way ;)

Not really; 1.4.2B doesn't make sense given the current priority
encoding, here 'release' ("", A, B, etc.) has "precedence" over
patchlevel.  It'd have to be though of as 1.4B.2{,_BETA}.

There's no way to represent 'version on release branch' other than
alpha, beta, or similar (in what you propose as the 'l' field).



cgd
-- 
Chris Demetriou - cgd@netbsd.org - http://www.netbsd.org/People/Pages/cgd.html
Disclaimer: Not speaking for NetBSD, just expressing my own opinion.