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
--
Fedora-packaging mailing list
Fedora-packaging@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-packaging
