What's in an Ubuntu package version string?

Here's a typical example:

corosync 2.3.3-1ubuntu1

The part before the hyphen (2.3.3) is the "upstream version". This is the version of the release tarball from upstream that the package is based on.

The part after the hyphen (1ubuntu1) is the packaging revision. But this splits further into the part before ubuntu and the part after. The part before (1) is the Debian packaging revision the packaging in Ubuntu is based on. The part after (also 1 in this case) is the Ubuntu packaging revision.

So here's how we can interpret this. The ubuntu tells us that there are Ubuntu specific changes that have been made in the package. The string after it (1) is the packaging revision assigned by the Ubuntu developer, and suggests that it has only been modified once. Going backwards, we can see that this Ubuntu modified package is based on Debian's package of corosync version 2.3.3-1. The Debian maintainer has assigned packaging revision 1 also, and his package is based on corosync's upstream release version 2.3.3.

Another example:

apache2 2.4.10-8ubuntu2

This package has also been modified from Debian, since ubuntu is present in the version string. It is on the second revision of packaging modifications in Ubuntu, and these modifications are based on the eighth Debian maintainer's packaging revision of upstream's 2.4.10 release.

Being in sync

haproxy 1.5.10-1

The absence of an ubuntu string inside the version number tells us that this package source has not been modified from Debian. We usually describe this as being "in sync" with Debian, which is a common goal for us in Ubuntu for most packages. This is the first Debian packaging revision of upstream haproxy's 1.5.10 release.

Not directly based on Debian

libvirt 1.2.8-0ubuntu19

The -0ubuntu tells us that this package is not based on Debian's packaging of upstream release 1.2.8 at all. This may be for a number of reasons, which cannot be determined solely from the version number:

Ubuntu may have pushed ahead with a newer upstream release of 1.2.8 before Debian uploaded it. This can happen when Ubuntu developers have a tighter deadline than Debian for a particular version. For example, since Ubuntu has a faster release cycle than Debian, it may be the case that a Debian maintainer hasn't had time to upload to Debian yet, but an Ubuntu developer wants to make the shorter deadline of an imminent Ubuntu release.
The package doesn't exist in Debian at all. This isn't ideal, but happens for very Ubuntu-specific packages. An example of this is nvidia-304, which is a "restricted" component binary non-free driver.
Ubuntu developers have decided to deliberately diverge from Debian for some reason. We try to avoid this situation as much as possible, but the situation does exist for some packages.

SRUs

vsftpd 3.0.2-1ubuntu2.14.04.1

This follows a common scheme used for updates to a stable release (a Stable Release Update, or SRU), where it is often necessary to "insert" a version in between the version in the stable release and version in a future release, so that upgrades to future releases still work correctly.

Use of this scheme isn't mandatory, but unless an Ubuntu developer is trying to be misleading, this version string means that the second Ubuntu modified packaging revision (ubuntu2) of the first Debian packaging revision (-1) of the upstream vsftpd release 3.0.2 has had one SRU (.1) applied to it in the 14.04 release. See the wiki page on security update preparation for more details of this scheme, which is also the recommended scheme to use for non-security updates.

Another (possibly more) common pattern you'll see in SRU version numbers is:

freeipmi 1.1.5-3ubuntu3.1

This uses the same scheme. But here, "inserting" a version didn't need the 14.04 style prefix since the same 1.1.5-3ubuntu3 didn't appear in multiple releases. So, a little more straightforwardly, this has had one SRU (.1) applied to the third (3) Ubuntu (ubuntu) modification of the third (-3) Debian packaging revision of upstream freeipmi release 1.1.5.

Comparing version numbers

Underpinning all of this is the definition of how Debian and Ubuntu package version numbers are compared. A strict ordering is defined in Debian policy, and familiarity with the scheme is essential for package maintainers. When in doubt, dpkg --compare-versions can verify the ordering for you.

Autosync

It is useful to know that the way that autosync mechanism prevents Ubuntu-specific changes from being overwritten is by detecting ubuntu in the version string. This is how, for example, no-change rebuilds are automatically synced over, but regular packages with Ubuntu deltas present are not.

Edge cases

Unfortunately, there are many edge cases which make it difficult to write a comprehensive guide. Here are some that come to mind that you can expect to eventually come across:

Native packages (eg. dpkg) have no packaging revision and so have no hyphen.
Hyphens are permitted in upstream version numbers, which leads to multiple hyphens in the Debian package version string!
Upstream release tarballs that contain files that cannot be redistributed by Debian or Ubuntu for legal reasons are modified by the maintainer to meet policy, and then grow something like +dfsg to the "upstream" version string.
A tilde (~) is defined to sort before anything else, including nothing. So it's used to "insert" a version before a standard one. This is commonly used in PPAs and backports.
Version epochs prefix a number followed by a colon to "reset" version numbers, for example when an upstream version numbering scheme changes and a newer version number would otherwise evaluate "backwards".
No change rebuilds lead to versions numbers like 1.5.2-3build1.
Versions "in the middle". I've said things like "second" and "eighth" above, but without checking we don't know for example that there wasn't an extra 2.4.10-6.1 revision in between 2.4.10-6 and 2.4.10-7, so this isn't strictly correct. We can't assume the number of versions that exist between two version strings based just on the version strings. The version numbering system is deliberately designed so that it is always possible to create a new version string in the middle.
Debian non-maintainer uploads (NMUs) use an additional suffix instead of bumping the first part of the packaging revision number as the maintainer would. This is to prevent any conflicts with an upload the maintainer might be preparing, and has the benefit of making it clear to others that an NMU took place.