3.2. The version of a package

Every package has a version number recorded in its Version control file field, described in Version.

The package management system imposes an ordering on version numbers, so that it can tell whether packages are being up- or downgraded and so that package system front end applications can tell whether a package it finds available is newer than the one installed on the system. The version number format has the most significant parts (as far as comparison is concerned) at the beginning.

If an upstream package has problematic version numbers they should be converted to a sane form for use in the Version field.

3.2.1. Version numbers based on dates

In general, Debian packages should use the same version numbers as the upstream sources. However, upstream version numbers based on some date formats (sometimes used for development or “snapshot” releases) will not be ordered correctly by the package management software. For example, dpkg will consider “96May01” to be greater than “96Dec24”.

To prevent having to use epochs for every new upstream version, the date-based portion of any upstream version number should be given in a way that sorts correctly: four-digit year first, followed by a two-digit numeric month, followed by a two-digit numeric date, possibly with punctuation between the components.

Native Debian packages (i.e., packages which have been written especially for Debian) whose version numbers include dates should also follow these rules. If punctuation is desired between the date components, remember that hyphen (-) cannot be used in native version numbers. Period (.) is normally a good choice.

3.2.2. Uniqueness of version numbers

The part of the version number after the epoch must not be reused for a version of the package with different contents once the package has been accepted into the archive, even if the version of the package previously using that part of the version number is no longer present in any archive suites.

This uniqueness requirement applies to the version numbers of source packages and of binary packages, even if the source package producing a given binary package changes. Thus the version numbers which a binary package must not reuse includes the version numbers of any versions of the binary package ever accepted into the archive, under any source package.

Additionally, for non-native packages, the upstream version must not be reused for different upstream source code, so that for each source package name and upstream version number there exists exactly one original source archive contents (see Files).

The reason for these restrictions is as follows. Epochs are not included in the names of the files that compose source packages, or in the filenames of binary packages, so reusing a version number, even if the epoch differs, results in identically named files with different contents. This can cause various problems.

If you find yourself wanting to reuse the part of a version number after the epoch, you can just increment the Debian revision, which doesn’t need to start at 1 or be consecutive.