12

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.

5 Answers 5

5

The official rpm guidelines tell how to do this, and links to an examples page. Here is an example of how you would work with the very common versioning scheme that uses three levels of pre-release (a,b,rc) (which rpm unfortunately makes it slightly complicated to support):

  • 1.0.0a1 -> 1.0.0-0.1.a1
  • 1.0.0b1 -> 1.0.0-0.1.b1
  • 1.0.0b2 -> 1.0.0-0.1.b2
  • 1.0.0b2, second release (packaging tweak of 1.0.0b2) -> 1.0.0-0.2.b2
  • 1.0.0rc1 -> 1.0.0-0.1.rc1
  • 1.0.0 -> 1.0.0-1
  • 1.0.1a1 -> 1.0.1-0.1.a1
  • 1.0.1 -> 1.0.1-1
3
  • Nice! Thank you very much for this. Just one thing in your example, it seems to me that 1.0.0-0.1.rc1 will be sorted as older than 1.0.0-0.2.b2, surely? So, as soon as the "-0.1" component is bumped to "-0.2", this should remain "-0.2" in all future version numbers. Do I understand right? Aug 29, 2017 at 9:30
  • I think you are correct. I will double check on the right way to do this properly and update my answer.
    – stochastic
    Aug 30, 2017 at 20:58
  • So which is the right way?
    – Sam
    Apr 5, 2018 at 14:29
6

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.

1
  • 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. Dec 7, 2012 at 15:53
2

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

How I do it: I like the major.minor.build 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.

1
  • 1
    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 :/ Dec 7, 2012 at 15:54
1

I bumped into a similar problem and I had to compare revisions between RedHat, Debian, Python packages and Ruby gems to unify the suite number, and this helped me to evaluate the "greater than" and "less than" in each case:

This is comparing 1.3.0.post0.dev20180213210433 to 1.3.0, YMMV

for Red Hat (thanks to https://utcc.utoronto.ca/~cks/space/blog/linux/RPMShellVersionComparison )

docker run -ti centos:7
yum install rpmdevtools.noarch
rpmdev-vercmp "1.3.0" "1.3.0.post0.dev20180213210433" 
1.3.0 < 1.3.0.post0.dev20180213210433

For Debian:

$ dpkg --compare-versions 1.3.0 gt 1.3.0.post0.dev20180213210433 ; echo $?
1  # false
$ dpkg --compare-versions 1.3.0 lt 1.3.0.post0.dev20180213210433 ; echo $?
0  # true

For Python

>>> from pkg_resources import parse_version
>>> parse_version("1.3.0") > parse_version("1.3.0.post0.dev20180213210433")
False
>>> parse_version("1.3.0") < parse_version("1.3.0.post0.dev20180213210433")
True

For Ruby

irb(main):001:0> Gem::Version.new("1.3.0") > Gem::Version.new("1.3.0.post0.dev20180213210433")
=> true
irb(main):002:0> Gem::Version.new("1.3.0") < Gem::Version.new("1.3.0.post0.dev20180213210433")
=> false
0

As of version 4.10.0, RPM officially supports the dpkg-style tilde numbering mentioned in the question.

https://rpm.org/wiki/Releases/4.10.0

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .