A variety of version numbering schemes have been created to keep track of different versions of a piece of software. The ubiquity of computers has also led to these schemes being used in contexts outside computing.
In sequence-based software versioning schemes, each software release is assigned a unique identifier that consists of one or more sequences of numbers or letters. This is the extent of the commonality; however, schemes vary widely in areas such as the quantity of sequences, the attribution of meaning to individual sequences, and the means of incrementing the sequences.
In some schemes, sequence-based identifiers are used to convey the significance of changes between releases. Changes are classified by significance level, and the decision of which sequence to change between releases is based on the significance of the changes from the previous release, whereby the first sequence is changed for the most significant changes, and changes to sequences after the first represent changes of decreasing significance.
Depending on the scheme; significance may be assessed by lines of code changed, function points added or removed, potential impact on customers in terms of work required to adopt a newer version, risk of bugs or undeclared breaking changes, degree of changes in visual layout, quantity of new features, or almost anything the product developers or marketers deem to be significant, including marketings desire to stress the "relative goodness" of the new version.
Semantic versioning (aka SemVer), currently the best known and most widely adopted version scheme in this category, uses a sequence of three digits (Major.Minor.Patch), an optional prerelease tag and optional build meta tag. In this scheme, risk and functionality are the measures of significance. Breaking changes are indicated by increasing the major number (high risk), new non-breaking features increment the minor number (medium risk) and all other non-breaking changes increment the patch number (lowest risk). The presence of a prerelease tag (-alpha, -beta) indicates substantial risk, as does a major number of zero (0.y.z), which is used to indicate a work-in-progress that may contain any level of potentially breaking changes (highest risk).
Developers may choose to jump multiple minor versions at a time to indicate significant features have been added, but are not enough to warrant incrementing a major version number; for example Internet Explorer 5 from 5.1 to 5.5, or Adobe Photoshop 5 to 5.5. This may be done to emphasize the value of the upgrade to the software user, or, as in Adobe's case, to represent a release halfway between major versions (although levels of sequence based versioning are not limited to a single digit, as in Drupal version 7.12).
A different approach is to use the major and minor numbers, along with an alphanumeric string denoting the release type, e.g. "alpha" (a), "beta" (b), or "release candidate" (rc). A software release train using this approach might look like 0.5, 0.6, 0.7, 0.8, 0.9 → 1.0b1, 1.0b2 (with some fixes), 1.0b3 (with more fixes) → 1.0rc1 (which, if it is stable enough), 1.0rc2 (if more bugs are found) → 1.0. It is a common practice in this scheme to lock-out new features and breaking changes during the release candidate phases and for some teams, even betas are lock-down to bug fixes only, in order to ensure convergence on the target release.
Other schemes impart meaning on individual sequences:
- major.minor[.build[.revision]] (example: 22.214.171.124)
- major.minor[.maintenance[.build]] (example: 126.96.36.19949)
Again, in these examples, the definition of what constitutes a "major" as opposed to a "minor" change is entirely subjective and up to the author, as is what defines a "build", or how a "revision" differs from a "minor" change.
Shared libraries in Solaris and Linux may use the current.revision.age  format where 
- current: The most recent interface number that the library implements.
- revision: The implementation number of the current interface.
- age: The difference between the newest and oldest interfaces that the library implements.
A similar problem of relative change significance and versioning nomenclature exists in book publishing, where edition numbers or names can be chosen based on varying criteria.
In most proprietary software, the first released version of a software product has version 1.
Degree of compatibility
Some projects use the major version number to indicate incompatible releases. Two examples are Apache APR and the FarCry CMS.
is a formal convention for specifying compatibility using a three-part version number: major version; minor version; and patch. The patch number is incremented for minor changes and bug fixes which do not change the software's application programming interface (API). The minor version is incremented for releases which add new, but backward-compatible, API features, and the major version is incremented for API changes which are not backward-compatible. For example, software which relies on version 2.1.5 of an API is compatible with version 2.2.3, but not necessarily with 3.2.4.
Often programmers write new software to be backward compatible, i.e., the new software is designed to interact correctly with older versions of the software (using old protocols and file formats) and the most recent version (using the latest protocols and file formats).
For example, IBM z/OS is designed to work properly with 3 consecutive major versions of the operating system running in the same sysplex.
This enables people who run a high availability computer cluster to keep most of the computers up and running while one machine at a time is shut down, upgraded, and restored to service.
Often and file format include a version number – sometimes the same as the version number of the software that wrote it; other times a "protocol version number" independent of the software version number.
The code to handle old deprecated protocols and file formats is often seen as cruft.
Designating development stage
Some schemes use a zero in the first sequence to designate alpha or beta status for releases that are not stable enough for general or practical deployment and are intended for testing or internal use only.
It can be used in the third position:
- 0 for alpha (status)
- 1 for beta (status)
- 2 for release candidate
- 3 for (final) release
- 188.8.131.52 instead of 1.2-a1
- 184.108.40.206 instead of 1.2-b2 (beta with some bug fixes)
- 220.127.116.11 instead of 1.2-rc3 (release candidate)
- 18.104.22.168 instead of 1.2-r (commercial distribution)
- 22.214.171.124 instead of 1.2-r5 (commercial distribution with many bug fixes)
There are two schools of thought regarding how numeric version numbers are incremented. Most free and open-source software packages, including MediaWiki, treat versions as a series of individual numbers, separated by periods, with a progression such as 1.7.0, 1.8.0, 1.8.1, 1.9.0, 1.10.0, 1.11.0, 1.11.1, 1.11.2, and so on. On the other hand, some software packages identify releases by decimal numbers: 1.7, 1.8, 1.81, 1.82, 1.9, etc. Decimal versions were common in the 1980s, for example with NetWare, DOS, and Microsoft Windows, but even in the 2000s have been for example used by Opera and Movable Type. In the decimal scheme, 1.81 is the minor version following 1.8, while maintenance releases (i.e. bug fixes only) may be denoted with an alphabetic suffix, such as 1.81a or 1.81b.
The standard GNU version numbering scheme is major.minor.revision, but emacs is a notable example using another scheme where the major number (1) was dropped and a user site revision was added which is always zero in original emacs packages but increased by distributors. Similarly, Debian package numbers are prefixed with an optional "epoch", which is used to allow the versioning scheme to be changed.
When printed, the sequences may be separated with characters. The choice of characters and their usage varies by scheme. The following list shows hypothetical examples of separation schemes for the same release (the thirteenth third-level revision to the fourth second-level revision to the second first-level revision):
- A scheme may use the same character between all sequences: 2.4.13, 2/4/13, 2-4-13
- A scheme choice of which sequences to separate may be inconsistent, separating some sequences but not others: 2.413
- A scheme's choice of characters may be inconsistent within the same identifier: 2.4_13
When a period is used to separate sequences, it may or may not represent a decimal point, — see “Incrementing sequences” section for various interpretation styles.
Number of sequences
There is sometimes a fourth, unpublished number which denotes the software build (as used by Microsoft). Adobe Flash is a notable case where a four-part version number is indicated publicly, as in 10.1.53.64. Some companies also include the build date. Version numbers may also include letters and other characters, such as Lotus 1-2-3 Release 1a.
Using negative numbers
Some projects use negative version numbers. One example is the SmartEiffel compiler which started from -1.0 and counted upwards to 0.0.
Date of release
The Wine project formerly used a date versioning scheme, which uses the year followed by the month followed by the day of the release; for example, "Wine 20040505". Ubuntu Linux uses a similar versioning scheme—Ubuntu 11.10, for example, was released October 2011. Some video games also use date as versioning, for example the arcade game Street Fighter EX. At startup it displays the version number as a date plus a region code, for example 961219 ASIA.
When using dates in versioning, for instance, file names, it is common to use the ISO 8601 scheme: YYYY-MM-DD, as this is easily string sorted to increasing/decreasing order. The hyphens are sometimes omitted.
Microsoft Office build numbers are an encoded date: the first two digits indicate the number of months that have passed from the January of the year in which the project started (with each major Office release being a different project), while the last two digits indicate the day of that month. So 3419 is the 19th day of the 34th month after the month of January of the year the project started.
Other examples that identify versions by year include Adobe Illustrator 88 and WordPerfect Office 2003. When a date is used to denote version, it is generally for marketing purposes, and an actual version number also exists. For example, Microsoft Windows 95 is internally versioned as MS-DOS 7.00 and Windows 4.00; likewise, Microsoft Windows 2000 Server is internally versioned as Windows NT 5.0 ("NT" being a reference to the original product name).
The Python Software Foundation has published PEP 440 -- Version Identification and Dependency Specification, outlining their own flexible (complicated) scheme, that defines an epoch segment, a release segment, prerelease and post-release segments and a development release segment.
TeX has an idiosyncratic version numbering system. Since version 3, updates have been indicated by adding an extra digit at the end, so that the version number asymptotically approaches π; this is a form of unary numbering – the version number is the number of digits. The current version is 3.14159265. This is a reflection of the fact that TeX is now very stable, and only minor updates are anticipated. TeX developer Donald Knuth has stated that the "absolutely final change (to be made after [his] death)" will be to change the version number to π, at which point all remaining bugs will become permanent features.
In a similar way, the version number of METAFONT asymptotically approaches e.
Apple has a formalized version number structure based around the NumVersion struct, which specifies a one- or two-digit major version, a one-digit minor version, a one-digit "bug" (i.e. revision) version, a stage indicator (drawn from the set development/prealpha, alpha, beta and final/release), and a one-byte (i.e. having values in the range 0–255) pre-release version, which is only used at stages prior to final. In writing these version numbers as strings, the convention is to omit any parts after the minor version whose value are zero (with "final" being considered the zero stage), thus writing 1.0.2 (rather than 1.0.2b12), 1.0.2 (rather than 1.0.2f0), and 1.1 (rather than 1.1.0f0).
Some software producers use different schemes to denote releases of their software. For example, the Microsoft Windows operating system was first labelled with standard version numbers for Windows 1.0 through Windows 3.11. After this Microsoft excluded the version number from the product name. For Windows 95 (version 4.0), Windows 98 (4.10) and Windows 2000 (5.0), year of the release was included in the product title. After Windows 2000, Microsoft created the Windows Server family which continued the year-based style with a difference: For minor releases, Microsoft suffixed "R2" to the title, e.g., Windows Server 2008 R2. This style had remained consistent to this date. The client versions of Windows however did not adopt a consistent style. First, they received names with arbitrary alphanumeric suffixes as with Windows ME (4.90), Windows XP (5.1) and Windows Vista (6.0). Then, once again Microsoft adopted incremental numbers in the title, but this time, they were not version numbers; the version numbers of Windows 7, Windows 8 and Windows 8.1 are respectively 6.1, 6.2 and 6.3. In Windows 10, the version number leaped to 10.0.
The Debian project uses a major/minor versioning scheme for releases of its operating system, but uses code names from the movie Toy Story during development to refer to stable, unstable and testing releases.
BLAG Linux and GNU features very large version numbers: major releases have numbers such as 50000 and 60000, while minor releases increase the number by 1 (e.g. 50001, 50002). Alpha and beta releases are given decimal version numbers slightly less than the major release number, such as 19999.00071 for alpha 1 of version 20000, and 29999.50000 for beta 2 of version 30000. Starting at 9001 in 2003, the most recent version as of 2011 is 140000.