Version numbering

Software versioning is the process of assigning either unique version names or unique version numbers to unique states of computer software. Within a given version number category (major, minor), these numbers are generally assigned in increasing order and correspond to new developments in the software. At a fine-grained level, revision control is often used for keeping track of incrementally different versions of electronic information, whether or not this information is computer software.

Modern computer software is often tracked using two different software versioning schemes—an internal version number that may be incremented many times in a single day, such as a revision control number, and a released version that typically changes far less often, such as semantic versioning or a project code name.

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.

For instance, in a scheme that uses a four-sequence identifier, the first sequence may be incremented only when the code is completely rewritten, while a change to the user interface or the documentation may only warrant a change to the fourth sequence.

This practice permits users (or potential adopters) to evaluate how much real-world testing a given software release has undergone. If changes are made between, say, 1.3rc4 (a release candidate) and the production release of 1.3, then that release, which asserts that it has had a production-grade level of testing in the real world, in fact contains changes which have not necessarily been tested in the real world at all. This approach commonly permits the third level of numbering ("change"), but does not apply this level of rigor to changes in that number: 1.3.1, 1.3.2, 1.3.3, 1.3.4... 1.4.1, etc.

...
Wikipedia