Incremental RPM package version "numbers" for x.y.z > x.y.z-beta (or alpha, rc, etc)

Jonathan Clarke asked:

In order to publish RPM packages of several different versions of some software, I’m looking for a way to specify version “numbers” that are considered “upgrades”, and include the differentiation of several pre-release versions, such as (in order): “2.4.0 alpha 1”, “2.4.0 alpha 2”, “2.4.0 alpha 3”, “2.4.0 beta 1”, “2.4.0 beta 2”, “2.4.0 release candidate”, “2.4.0 final”, “2.4.1”, “2.4.2”, etc.

The main issue I have with this is that RPM considers that “2.4.0” comes earlier than “2.4.0.alpha1”, so I can’t just add the suffix on the end of the final version number.

I could try “2.4.0.alpha1”, “2.4.0.beta1”, “2.4.0.final”, which would work, except for the “release candidate” that would be considered later than “2.4.0.final”.

An alternative I considered is using the “epoch:” section of the RPM version number (the epoch: prefix is considered before the main version number so that “1:2.4.0” is actually earlier than “2:1.0.0”). By putting a timestamp in the epoch: field, all the versions get ordered as expected by RPM, because their versions appear to increment in time. However, this fails when new releases are made on several major versions at the same time (for example, 2.3.2 is released after 2.4.0, but their version for RPM are “20121003:2.3.2” and “20120928:2.4.0” and systems on 2.3.2 can’t get “upgraded” to 2.4.0, because rpm sees it as an older version). In this case, yum/zypper/etc refuse to upgrade to 2.4.0, thus my problem.

What version numbers can I use to achieve this, and make sure that RPM always considers the version numbers to be in order. Or if not version numbers, other mechanism in RPM packaging?

Note 1: I would like to keep the “Release:” field of the spec file for it’s original purpose (several releases of packages, including packaging changes, for the same version of the packaged software).

Note 2: This should work on current production versions of major distributions, such as RHEL/CentOS 6 and SLES 11. But I’m interested in solutions that don’t, too, so long as they don’t involve recompiling rpm!

Note 3: On Debian-like systems, dpkg uses a special component in the version number which is the “~” (tilde) character. This causes dpkg to count the suffix as “negative” ordering, so that “2.4.0~anything” will come before “2.4.0”. Then, normal ordering applies after the “~”, so “2.4.0~alpha1” comes before “2.4.0~beta1” because “alpha” comes before “beta” alphabetically. I’m not necessarily looking to use the same scheme for RPM packages (I’m pretty sure no such equivalent exists), so this is just FYI.

My answer:


Fedora has a set of guidelines for setting the version/release number of pre-release packages. Basically you use the version number of what will be the final release in Version, and start the Release number with 0., an incrementing number, and then alpha, beta or whatever. You would not use an alphanumeric tag final for the final release at all.

Note that you cannot count on RPM having support for the Debian-style tilde versioning. Several distributions disable this feature.


View the full question and answer on Server Fault.

Creative Commons License
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.