[Fedora-packaging] release tag question.
bugs.michael at gmx.net
Thu Jun 22 11:22:45 UTC 2006
On Thu, 22 Jun 2006 15:24:04 +1200, Michael J. Knox wrote:
> 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:
A bit wierd to not separate '9' and 'h' with a dot, but:
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:
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).
More information about the Fedora-packaging