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