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