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

Solution 1:

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.

Solution 2:

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

---

Solution 3:

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.