Version Number

Most projects have a version number. Even smaller units like files or functions may have their own version numbers. Which version numbering schemes do exist and what are their pros and cons?

Common Version Number Format

Many projects use a version like major[.minor[.micro[.build]]], where major, minor, micro, and build are nonnegative integers. The micro component is sometimes called the patchlevel.

Some projects append a string like "rc", "alpha", "beta", all followed by a small positive integer, to the last component they use to indicate versions that are "almost" finished.

Meaning of the Version Number Components

The Linux kernel (http://www.kernel.org/) uses even minor numbers for release versions, and odd minor numbers for development versions. The development version major.minor evolves from major.(minor-1) and leads to major.(minor+1) or (major+1).0.

The Wine project (http://www.winehq.com/) uses the release date as a single component version number.

Version Numbers for Shared Libraries

Every shared library should have a version number. This number may be different from the version number of the project, in which the library is distributed.

• The major number should be increased whenever the API changes in an incompatible way.
• The minor number should be increased whenever the API changes in a compatible way.
• The micro number should be increased whenever the implementation changes, while the API does not.

---

Alternative Version Number Format

An alternative version number format proposed by David Tanzer (http://davidtanzer.net/node/75) is v[major][qualifier][revision] where "major" and "revision" are positive integers and "qualifier" is one of the following:

• "ds": Development snapshot
• "be": Beta
• "rc": Release Candidate
• "pr": Production
• "mr": Maintenance Release

Example: "libfoo-v01ds05". --David Tanzer