Software versioning
Software versioning is the process of assigning unique version names or unique version numbers to unique states of computer software. The most widely adopted scheme for version numbers is known as semantic versioning, which comprises a three-part version number, an optional prerelease tag, and an optional build meta tag. A fourth number may also be used to denote the software build, as was the case for Adobe Flash. Some companies also rely on the build date, in a system known as calendar versioning, and letters and other characters, such as Lotus 1-2-3 Release 1a.
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.8.1, 1.9.0. On the other hand, some software packages identify releases by decimal numbers: 1.8, 1.81, 1.82. Developers may choose to jump multiple minor versions at a time to indicate that significant features have been added or for marketing purposes. Version numbers are often used to identify copies of a software product and compare them against another copy in a collaborative version control system.
Within software development teams, version control is used to keep track of incrementally-different versions of information in order to be able to roll any changes back. Modern computer software is often tracked using two different software versioning schemes: an internal version number, which may be incremented many times in a single day, and a release version, which typically changes far less often.
Historically, file numbers were especially used in public administration and corporations to uniquely identify files or cases. This practice was introduced to computer files for the first time with MIT's ITS file system, later the TENEX file system for the PDP-10 in 1972. In the 21st century, more programmers started to use a standardized version policy, such as the semantic versioning policy, which is particularly useful when using software libraries, frameworks, and command-line applications.
History
File numbers were used especially in public administration, as well as companies, to uniquely identify files or cases. For computer files this practice was introduced for the first time with MIT's ITS file system, later the TENEX filesystem for the PDP-10 in 1972.Later lists of files including their versions were added, and dependencies amongst them. Linux distributions like Debian, with its dpkg, early on created package management software which could resolve dependencies between their packages. Debian's first try was that a package knew other packages which depended on it. From 1994 on this idea was inverted, so a package that knew the packages it needed. When installing a package, dependency resolution was used to automatically calculate the packages needed as well, and install them with the desired package. To facilitate upgrades, minimum package versions were introduced. Thus the numbering scheme needed to tell which version was newer than the required one.
Schemes
Based on sequence identifiers
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; schemes vary widely in areas such as the number of sequences, the attribution of meaning to individual sequences, and the means of incrementing the sequences.Change significance
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, the potential impact on customers in terms of work required to adopt a new version, risk of bugs or undeclared breaking changes, degree of changes in visual layout, the number of new features, or almost anything the product developers or marketers deem to be significant, including marketing desire to stress the "relative goodness" of the new version.
Semantic versioning
is a widely adopted version scheme that encodes a version by a three-part version number, an optional prerelease tag, and an optional build meta tag. In this scheme, risk and functionality are the measures of significance. Breaking changes are indicated by increasing the major number ; new, non-breaking features increment the minor number ; and all other non-breaking changes increment the patch number. The presence of a prerelease tag indicates substantial risk, as does a major number of zero, which is used to indicate a work-in-progress that may contain any level of potentially breaking changes. As an example of inferring compatibility from a SemVer version, 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.Other schemes
A fourth number may also be used to denote the software build, as was the case for Adobe Flash. Some companies also include the build date and letters and other characters, such as Lotus 1-2-3 Release 1a.Developers may choose to jump multiple minor versions at a time to indicate that 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.
A different approach is to use the major and minor numbers along with an alphanumeric string denoting the release type, e.g. "alpha", "beta", or "release candidate". A software release train using this approach might look like 0.5, 0.6, 0.7, 0.8, 0.9 → 1.0b1, 1.0b2, 1.0b3 → 1.0rc1, 1.0rc2 → 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 locked down to bug fixes only, to ensure convergence on the target release.
Other schemes impart meaning on individual sequences:
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 Linux and Solaris may use the
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 Portable Runtime and the FarCry CMS.Often programmers write new software to be backward compatible. 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 packet headers 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
Software in the experimental stage often uses a zero in the first position of the sequence to designate its status. However, this scheme is only useful for the early stages, not for upcoming releases with established software where the version number has already progressed past 0.A number of schemes are used to denote the status of a newer release:
- Alphanumeric suffix is a common scheme adopted by semantic versioning. In this scheme, versions have affixed a dash plus some alphanumeric characters to indicate the status.
- Numeric status is a scheme that uses numbers to indicate the status as if it's part of the sequence. A typical choice is the third position for the four-position versioning.
- Numeric 90+ is another scheme that uses numbers, but apparently under a number of a previous version. A large number in the last position, typically 90 or higher, is used. This is commonly used by older open-source projects like Fontconfig.
| Development stage | Semantic versioning | Numeric status | Numeric 90+ |
| Alpha | 1.2.0-a.1 | 1.2.0.1 | 1.1.90 |
| Beta | 1.2.0-b.2 | 1.2.1.2 | 1.1.93 |
| Release candidate | 1.2.0-rc.3 | 1.2.2.3 | 1.1.97 |
| Release | 1.2.0 | 1.2.3.0 | 1.2.0 |
| Post-release fixes | 1.2.5 | 1.2.3.5 | 1.2.5 |
The two purely numeric forms remove the special logic required to handle the comparison of "alpha < beta < rc < no prefix" as found in semantic versioning, at the cost of clarity.
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 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 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.
In some cases, developers may decide to reset the major version number. This is sometimes used to denote a new development phase being released. For example, Minecraft Alpha ran from version 1.0.0 to 1.2.6, and when Beta was released, it reset the major version number and ran from 1.0 to 1.8. Once the game was fully released, the major version number again reset to 1.0.0.