Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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", "", which would work, except for the "release candidate" that would be considered later than "".

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.

share|improve this question

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.

share|improve this answer
Thanks, I will look into these. At first glance, it seems that they are "hi-jacking" the Release component to allow for upstream alpha/beta/etc versions, which I find a bit cumbersome... IMO, Release should be incremented for packging changes, not for changes in the packaged software. – Jonathan Clarke Dec 7 '12 at 15:53
All the RPM-based distributions do this, if they distribute alpha or beta software at all. – Michael Hampton Dec 7 '12 at 15:58

I am not a fan of alpha/beta distinctions. There is released code and unreleased code.

How I do it: I like the with a continuous integration system (see JenkinsCI). Build integer is never reset. Minor version number changes are for backwards compatible changes. Major number changes are big deals.

If marketing does not like the "build" to be large integers, you can increment the minor number once for marketing only on builds that are released, and then again when it goes to engineering.

share|improve this answer
Well, alpha/beta versions are also released... just not as a "Final" version. And I don't really have any choice about that, I just want to have the packaging follow :/ – Jonathan Clarke Dec 7 '12 at 15:54

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.