As I mentioned here, RPM package version numbers have three components: an 'epoch' number, the package's upstream version, and an RPM package release version. The epoch number is there because upstream developers sometimes change version numbers in ways that break RPM's normal version comparison algorithm, or just plain use odd version formats.

(For example, I believe there's at least one program that increments its version by adding another digit of π to the end of the version number. This makes perfect sense in a way, but is hard for RPM version comparison to cope with.)

In that other entry I wrote that the default epoch number was '1' (and then a commentator corrected me to say that it was '0'). Both of us turn out to be wrong. The default RPM versioning is to have no epoch number at all. A RPM package that does not specify an epoch number does not have an epoch of '0'; it has no epoch at all, which is displayed by RPM as '(none)'. A package with no epoch number is a lower version overall than any epoch number, even 0.

On all of the RPM-based machines that I have sitting around, no epoch is by far the most common epoch. The next most common epoch is actually '1', not '0'; one theory I have about this is that a lot of people who build RPMs also think that the default epoch is 0, so when they specify an explicit epoch to override the upstream version number they start from 1.

Across all of the packages that I have handy on my machines, the highest epoch number is 50 (on aspell-en, on Fedora 14, Fedora 15, and Fedora 16). Other high epochs (on Fedora 16) are 32 (for bind's packages), 14 (tcpdump plus libpcap), and 12 (dhcp and aspell).

If you want to check your own RPM-based systems, appropriate rpm commands are:

rpm -qa --qf '%{E}\n' | sort | uniq -c | sort -nr
rpm -qa --qf '%{E}:%{N}\n'

The first will show you a count of epoch numbers; the second will show you the epochs for all of your packages (so you can find, for example, the package or packages at epoch 50).