Software versioning

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.

Shared libraries in Solaris and Linux may use the current.revision.age format where:[8][9] 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.

For example, IBM z/OS is designed to work properly with 3 consecutive major versions of the operating system running in the same sysplex.

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.

[1] A number of schemes are used to denote the status of a newer release: The two purely numeric forms removes 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.

[14] 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.

[16] Similarly, Debian package numbers are prefixed with an optional "epoch", which is used to allow the versioning scheme to be changed.

[citation needed] When using dates in versioning, for instance, file names, it is common to use the ISO 8601 scheme[20] YYYY-MM-DD, as this is easily string-sorted in increasing or decreasing order.

Microsoft Office build numbers are an encoded date:[21] 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.

[citation needed] Other examples that identify versions by year include Adobe Illustrator 88 and WordPerfect Office 2003.

TeX has an idiosyncratic version numbering system, an unusual feature invented by its developer Donald Knuth.

Mac OS X departed from this trend, in large part because "X" (the Roman numeral for 10) was in the name of the product.

Windows 10 was initially intended to be NT 6.4, as the earliest Technical Preview build shared to the public is numbered 6.4.9841.

More recently, a number of other platforms including Firefox and Fenix for Android,[40] Eclipse,[41] LibreOffice,[42] Ubuntu,[43] Fedora,[44] Python,[45] digiKam[46] and VMware[47] have adopted the release train model.

As an example of surprising version number ordering implementation behavior, in Debian, leading zeroes are ignored in chunks, so that 5.0005 and 5.5 are considered as equal, and 5.5 < 5.0006.

This can confuse users; string-matching tools may fail to find a given version number; and this can cause subtle bugs in package management if the programmers use string-indexed data structures such as version-number indexed hash tables.

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.

[52] Since the internet has become widespread, most commercial software vendors no longer follow the maxim that a major version should be "complete" and instead rely on patches with bugfixes to sort out the known issues which a solution has been found for and could be fixed.

[citation needed] A relatively common practice is to make major jumps in version numbers for marketing reasons.

[citation needed] For example, as in the case of dBase II, a product is launched with a version number that implies that it is more mature than it is.

This can be seen in many examples of product version numbering by Microsoft, America Online, Sun Solaris, Java Virtual Machine, SCO Unix, WordPerfect.

[1] The purpose of such policies is to make it easier for other programmers to know when code changes are likely to break things they have written.

Version numbers allow people providing support to ascertain exactly which code a user is running, so that they can rule out bugs that have already been fixed as a cause of an issue, and the like.

The semantic meaning[1] of version.revision.change style numbering is also important to information technology staff, who often use it to determine how much attention and research they need to pay to a new release before deploying it in their facility.

This is one reason for some of the distaste expressed in the "drop the major release" approach taken by Asterisk et alia: now, staff must (or at least should) do a full regression test for every update.

Versioning amongst documents is relatively similar to the routine used with computers and software engineering, where with each small change in the structure, contents, or conditions, the version number is incremented by 1, or a smaller or larger value, again depending on the personal preference of the author and the size or importance of changes made.

A particularly notable usage is Web 2.0, referring to websites from the early 2000s that emphasized user-generated content, usability and interoperability.

Technical drawing and CAD software files may also use some kind of primitive versioning number to keep track of changes.