[Fedora-packaging] release tag question.

[Michael J. Knox]

Michael Schwendt wrote:
> On Thu, 22 Jun 2006 15:24:04 +1200, Michael J. Knox wrote:
> 
> 
>>Hi..
>>
>>Just looking at the cvsup package, as I need to use it at work. Anywho..
>>
>>Just curious the rationale for the release tag. The actual version of 
>>the package is 16.1h, but its packaged as 16.1 and the "h" is pushed out 
>>into the release tag. Like:
>>
>>cvsup-16.1-9h
> 
> 
> A bit wierd to not separate '9' and 'h' with a dot, but:
>  
> 
>>Why?
> 
> 
> It's the same old rationale. To avoid comparing numerical bits with
> non-numerical bits, as all digits are higher than all letters. It's _not_
> needed everytime there is a non-numerical piece in a version. But you
> cannot predict whether it will be needed some day when upstream changes
> versioning in a way that is incompatible with RPM version comparison.
> 
> Just like 1.0a (alpha pre-release) is newer than 1.0 (final release)
> and 2.0 (final) release is older than 2.0a (post-release fix) and
> 3.0rc4 (release candidate) is newer than 3.0c (post-release fix),
> and so on.
> 
> [There are other examples where RPM version comparison does not work with
> upstream versioning schemes. The most infamous example is 2.11 being a
> newer upstream release than 2.104 and the opposite for RPM.]
> 
> 
>>Would this not work:
>>
>>cvsup-16.1h-9
> 
> 
> 16.12 would be newer than 16.1x, 16.12 would be newer than 16.2c, too.
> Who knows what will come after 16.1h?
>  
> 
>>My first guess is that version comparisons would be messed up if the h 
>>was in the version tag, but then would it not mess up the release 
>>comparison also?
> 
> 
> Not if you move the non-numerical bit to the least-significant
> place (= the very right).

right, that makes sense. Thanks for clearing that up :)

Michael