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 (aka SemVer) is a widely adopted version scheme that encodes a version by a three-part version number (Major.Minor.Patch), 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 (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). 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 (although levels of sequence-based versioning are not necessarily limited to a single digit, as in
Blender version 2.91 or
Minecraft Java Edition starting from 1.7.10 through 1.21.11, after which the versioning scheme transitioned to a year-based format). 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 (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 locked down to bug fixes only, to ensure convergence on the target release. Other schemes impart meaning on individual sequences: :
major.minor[.build[.revision (example:
1.2.12.102) :
major.minor[.maintenance[.build (example:
1.4.3.5249) 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
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. This use of the third field is specific to
libtool: others may use a different meaning or simply ignore it. 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 (APR) 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 (
alpha or
beta) often uses a zero in the first ("major") 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. 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. 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.
Format Some projects use negative version numbers. One example is the
SmartEiffel compiler which started from −1.0 and counted upwards to 0.0. To ease sorting, some software packages represent each component of the
major.minor.release scheme with a fixed width. Perl represents its version numbers as a floating-point number; for example, Perl's 5.8.7 release can also be represented as 5.008007. This allows a theoretical version of 5.8.10 to be represented as 5.008010. Other software packages pack each segment into a fixed bit width; for example, on Microsoft Windows, version number 6.3.9600.16384 would be represented as
hexadecimal 0x0006000325804000. The floating-point scheme breaks down if any segment of the version number exceeds 999; a packed-binary scheme employing 16 bits apiece breaks down after 65535. Between the 1.0 and the 2.6.x series, the
Linux kernel used
odd minor version numbers to denote development releases and
even minor version numbers to denote stable releases. For example, Linux 2.3 was a development family of the second major design of the Linux kernel, and Linux 2.4 was the stable release family that Linux 2.3 matured into. After the minor version number in the Linux kernel is the release number, in ascending order; for example, Linux 2.4.0 → Linux 2.4.22. Since the 2004 release of the 2.6 kernel, Linux no longer uses this system, and has a much shorter release cycle. The same odd-even system is used by some other software with long release cycles, such as
Node.js up to version 0.12 as well as
WineHQ.
Based on date of release identifiers showing release number in
CalVer format: "961219 USA" Many projects use a date-based versioning scheme called
Calendar Versioning (aka
CalVer).
Ubuntu is one example of a project using calendar versioning; Ubuntu 18.04, for example, was released in April 2018. This has the advantage of being easily relatable to development schedules and support timelines. 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 in increasing or decreasing order. The hyphens are sometimes omitted. The
Wine project formerly used a date versioning scheme, which used the year followed by the month followed by the day of the release; for example, "Wine 20040505". The earliest development builds of
Minecraft had a similar version formatting, but instead used DDHHMM, for example rd-131655 was created on the 13th (of May 2009) at 16:21.
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 year is used to denote version, it is generally for marketing purposes, and an actual version number also exists. For example,
Windows 95 is internally versioned as
MS-DOS 7.00 and Windows 4.00; likewise,
Windows 2000 is internally versioned as NT 5.0.
Other schemes Some software producers use different schemes to denote releases of their software. 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.
Urbit uses
Kelvin versioning (named after the absolute
Kelvin temperature scale): software versions start at a high number and count down to version 0, at which point the software is considered finished and no further modifications are made.
Prerelease versions In conjunction with the various versioning schemes listed above, a system for denoting prerelease versions is generally used, as the program makes its way through the stages of the
software release life cycle. Programs that are in an early stage are often called "alpha" software, after the first letter in the Greek alphabet. After they mature but are not yet ready for release, they may be called "beta" software, after the second letter in the Greek alphabet. Generally alpha software is tested by developers only, while beta software is distributed for community testing. Some systems use numerical versions less than 1 (such as 0.9), to suggest their approach toward a final "1.0" release. This is a common convention in
open source software. However, if the prerelease version is for an existing software package (e.g. version 2.5), then an "a" or "alpha" may be appended to the version number. So the alpha version of the 2.5 release might be identified as 2.5a or 2.5.a. An alternative is to refer to prerelease versions as "release candidates", so that software packages which are soon to be released as a particular version may carry that version tag followed by "rc-#", indicating the number of the release candidate; when the final version is released, the "rc" tag is removed. ==Significance==