The number before the colon in a Debian version, as in 1:2.3.4-1, is the epoch. Debian compares the epoch first, as a plain number, before looking at anything else. A version with a higher epoch is newer regardless of the rest, and a missing epoch counts as zero.
The format
The Debian Policy Manual defines a package version as [epoch:]upstream_version[-debian_revision]. There are three parts.
The epoch is a single, generally small, unsigned integer. It may be omitted, in which case zero is assumed. Policy says epochs can help when the upstream version numbering scheme changes, but must be used with care, and that you should not change the epoch without consensus on the debian-devel list.
The upstream version is the main part, usually the version number of the original software. The Debian revision is the number after the last hyphen and tracks changes made by the Debian packager.
How comparison works
Policy states that when comparing two versions, the epochs are compared first, then the upstream version if the epochs are equal, then the Debian revision if the upstream versions are also equal. The epoch is compared numerically. The other two parts use a left to right algorithm that alternates between non digit and digit sections.
An example makes the effect plain:
| Version A | Version B | Which is newer |
|---|---|---|
| 1:1.0-1 | 2.0-1 | A, because epoch 1 beats the implied epoch 0 |
| 2.0-1 | 2.0-2 | B, same upstream, higher revision |
| 0:2.0-1 | 2.0-1 | Equal, since an omitted epoch is zero |
Version A looks older to a human eye because 1.0 is lower than 2.0. The epoch overrides that.
Why it matters for vulnerability scanning
Operating system advisories express affected and fixed versions in this format. If a scanner drops the epoch, or parses it incorrectly, it can compare the wrong values.
Take a fixed version of 1:2.3.4-1 in an advisory. If your installed package is 1:2.3.4-1, you are on the fix. If a tool strips the 1: from both, the result is the same, but if it strips it from only one side, the comparison no longer reflects the real ordering. Either error produces a wrong verdict.
Comparing only the upstream part can also give misleading answers, and the related post on backported fixes and Debian version numbers covers that side.
Steps to check a package by hand
- Read the full version from the package database, epoch included.
- Read the fixed version from the distribution advisory.
- Compare epochs as numbers.
- If they match, compare the upstream version, then the revision.
- Confirm that your SBOM stores the full string, epoch and revision both.
SBOM hygiene
Record the version exactly as the package manager reports it. A truncated version in an SBOM loses information you cannot recover later, and downstream tools will match against the wrong number. If your SBOM format has a separate field for qualifiers or a package URL, check where the epoch lands and test it with one real package.
Safeguard's SBOM and dependency scanning, and its free scan, let you inspect how container and project components are listed in an inventory.
Quick check
Is 1:1.0-1 newer than 2.0-1?
Yes. The epoch is compared first, and 1 is higher than the implied zero of the second version.
What if there is no epoch?
Policy says zero is assumed.
Sources
Last reviewed: 19 October 2026.
