https://bugzilla.redhat.com/show_bug.cgi?id=1264546 --- Comment #48 from Michael Schwendt <bugs.michael@xxxxxxx> --- It is not my duty to enforce the package versioning guidelines. I mentioned the guidelines, because %version 0.0.1.beta10 would be problematic, if there were a 0.0.1 final release. Same for a git snapshot made after 0.0.1 and before 0.0.2. Which %version to use then? The guidelines offer some flexibility for such scenarios. Discussing "the problem", mentioning the existing guidelines and tools like rpmdev-vercmp, may be sufficient. Still, occasionally packagers run into some of the pitfalls and then can't do much if they don't control upstream's versioning scheme. > $ rpmdev-vercmp 0.0.1-beta10.1 0.0.1-beta8.222 > 0.0.1-beta10.1 > 0.0.1-beta8.222 > $ rpmdev-vercmp 0.0.1-1 0.0.1-beta8.222 > 0.0.1-1 > 0.0.1-beta8.222 There are many schemes that seem to be compatible with RPM versioning comparison at first glance. For example, if comparing numbers with letters, numbers win always, so going from release beta8 to 1 seems to work. It can get awkward, if you publish builds for multiple distribution releases. Suddenly, the "beta8" at the most-significant left side of %release decides whether a package is newer than a build for another dist target. If you ever needed to rebuild a package for an older dist more often than for a newer dist, a different scheme is needed as not to compare build version with %{?dist}. It can also get troublesome, if you want to switch from a "beta" release to a git snapshot or vice versa. A real release number at the very left opens more opportunities to move pre-release and post-release version details to the less significant right side of %release. However, some of the problems are not encountered often, and an upstream versioning scheme that is fully compatible with RPM version comparison won't cause any problems. > and automated scripts cannot properly handle it. rpmdev-bumpspec as used during mass-rebuilds, handles Fedora's pre-release and post-release versioning schemes just fine. The only requirement is to avoid macro-madness in the Release tag. There are only a very few packages, which would win every spec file obfuscation contest and confuse rpmdev-bumpspec. -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component _______________________________________________ package-review mailing list package-review@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/package-review