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