Hubbry Logo
Software versioningSoftware versioningMain
Open search
Software versioning
Community hub
Software versioning
logo
7 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Software versioning
Software versioning
Software versioning
View on Wikipedia
from Wikipedia

Semantic versioning three-part version number

Software versioning is the process of assigning unique version names or unique version numbers to unique states of computer software. The most widely adopted[citation needed] scheme for version numbers is known as semantic versioning (SemVer), which comprises a three-part version number (Major.Minor.Patch), an optional pre-release tag (e.g. alpha, beta), 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,[1] which is particularly useful when using software libraries, frameworks, and command-line applications.

History

[edit]

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

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.[3][4][5]

Schemes

[edit]

Based on sequence identifiers

[edit]
An example version number sequence

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

[edit]

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

[edit]

Semantic versioning (aka SemVer)[1] is a widely adopted version scheme[7] that encodes a version by a three-part version number (Major.Minor.Patch), an optional pre-release 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 pre-release 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

[edit]

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.[citation needed]

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).

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:[8][9]

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.[citation needed]

Degree of compatibility

[edit]

Some projects use the major version number to indicate incompatible releases. Two examples are Apache Portable Runtime (APR)[10] and the FarCry CMS.[11]

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

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

[edit]

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:

  • Alphanumeric suffix is a common scheme adopted by semantic versioning.[1] 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.
Comparison of development stage indicators
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 (RC) 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[13] and Movable Type.[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.

The standard GNU version numbering scheme is major.minor.revision,[15] 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.[16] Similarly, Debian package numbers are prefixed with an optional "epoch", which is used to allow the versioning scheme to be changed.[17]

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

Format

[edit]

Some projects use negative version numbers. One example is the SmartEiffel compiler which started from −1.0 and counted upwards to 0.0.[16]

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

Based on date of release identifiers

[edit]
Street Fighter EX splash screen showing release number in CalVer format: "961219 USA"

Many projects use a date-based versioning scheme called Calendar Versioning (aka CalVer[20]).

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.[citation needed]

When using dates in versioning, for instance, file names, it is common to use the ISO 8601 scheme[21] 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".[citation needed] 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:[22] 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.[citation needed]

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

Other schemes

[edit]

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

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.[25][26][27]

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.[28][29]

Pre-release versions

[edit]

In conjunction with the various versioning schemes listed above, a system for denoting pre-release 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.[30][31] However, if the pre-release 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 pre-release 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

[edit]

Technical

[edit]

In software engineering

[edit]

Version numbers are used in practical terms by the consumer, or client, to identify or compare their copy of the software product against another copy, such as the newest version released by the developer. For the programmer or company, versioning is often used on a revision-by-revision basis, where individual parts of the software are compared and contrasted with newer or older revisions of those same parts, often in a collaborative version control system.

In the 21st century, more programmers started to use a formalized version policy, such as the semantic versioning policy.[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. Such policies are especially important for software libraries and frameworks, but may also be very useful for command-line applications (which may be called from other applications) and for other applications (which may be scripted and/or extended by third parties).

Release train

[edit]

A software release train is a form of software release schedule in which a number of distinct series of versioned software releases for multiple products are released as a number of different "trains" on a regular schedule. Generally, for each product line, a number of different release trains are running at a given time, with each train moving from initial release to eventual maturity and retirement on a planned schedule. Users may experiment with a newer release train before adopting it for production, allowing them to experiment with newer, "raw", releases early, while continuing to follow the previous train's point releases for their production systems prior to moving to the new release train as it becomes mature.

Cisco's IOS software platform used a release train schedule with many distinct trains for many years. More recently, a number of other platforms including Firefox and Fenix for Android,[32] Eclipse,[33] LibreOffice,[34] Ubuntu,[35] Fedora,[36] Python,[37] digiKam[38] and VMware[39] have adopted the release train model.

Internal version numbers

[edit]

Software may have an "internal" version number which differs from the version number shown in the product name (and which typically follows version numbering rules more consistently). Java SE 5.0, for example, has the internal version number of 1.5.0, and versions of Windows from NT 4 on have continued the standard numerical versions internally: Windows 2000 is NT 5.0, XP is Windows NT 5.1, Windows Server 2003 and Windows XP Professional x64 Edition are NT 5.2, Windows Server 2008 and Vista are NT 6.0, Windows Server 2008 R2 and Windows 7 are NT 6.1, Windows Server 2012 and Windows 8 are NT 6.2, and Windows Server 2012 R2 and Windows 8.1 are NT 6.3. 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. However, that did not last as the version of Windows 10 was quickly artificially increased to 10.0[40] to align with the commercial name, resulting in the first released version of the operating system being numbered 10.0.10240. Note, however, that Windows NT is only on its fifth major revision, as its first release was numbered 3.1 (to match the then-current Windows release number) and the Windows 10 launching made a version leap from 6.3 to 10.0.

Marketing

[edit]

A relatively common practice is to make major jumps in version numbers for marketing reasons. Sometimes software vendors just bypass the 1.0 release or quickly release a release with a subsequent version number because 1.0 software is considered by many customers too immature to trust with production deployments.[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.

Other times version numbers are increased to match those of competitors. This can be seen in many examples of product version numbering by Microsoft, America Online, Sun Solaris, Java Virtual Machine, SCO Unix, WordPerfect. Microsoft Access jumped from version 2.0 to version 7.0, to match the version number of Microsoft Word.

Microsoft has also been the target of "catch-up" versioning, with the Netscape browsers skipping version 5 to 6, in line with Microsoft's Internet Explorer, but also because the Mozilla application suite inherited version 5 in its user agent string during pre-1.0 development and Netscape 6.x was built upon Mozilla's code base. Another example of keeping up with competitors is when Slackware Linux jumped from version 4 to version 7 in 1999.[41]

This approach, panned by many because it breaks the semantic significance of the sections of the version number, has been adopted by an increasing number of vendors including Mozilla (for Firefox) and Google (for Google Chrome).[42]

Promoting minor as major

[edit]

Sun's Java has at times had a hybrid system, where the internal version number has always been 1.x but has been marketed by reference only to the x:

  • JDK 1.0.3
  • JDK 1.1.2 through 1.1.8
  • J2SE 1.2.0 ("Java 2") through 1.4.2
  • Java 1.5.0, 1.6.0, 1.7.0, 1.8.0 ("Java 5, 6, 7, 8")

Sun also dropped the first digit for Solaris, where Solaris 2.8 (or 2.9) is referred to as Solaris 8 (or 9) in marketing materials.

A similar jump took place with the Asterisk open-source PBX construction kit in the early 2010s, whose project leads announced that the current version 1.8.x would soon be followed by version 10.[43]

Political and cultural significance of version numbers

[edit]

Version 1.0 as a milestone

[edit]

The free-software and open source communities tend to release software early and often. Initial versions are numbers less than 1, with these 0.x version used to convey that the software is incomplete and not reliable enough for general release or usable in its current state. Backward-incompatible changes are common with 0.x versions. Version 1.0 is used as a major milestone, indicating that the software has at least all major features plus functions the developers wanted to get into that version, and is considered reliable enough for general release.[30][31] A good example of this is the Linux kernel, which was first released as version 0.01 in 1991,[44] and took until 1994 to reach version 1.0.0.[45]

The developers of the arcade game emulator MAME do not ever intend to release a version 1.0 of the program because there will always be more arcade games to emulate and thus the project can never be truly completed. Accordingly, version 0.99 was followed by version 0.100.[46]

Superstition

[edit]
  • The Office 2007 release of Microsoft Office had an internal version number of 12. The next version, Office 2010, has an internal version of 14, due to superstitions surrounding the number 13.[47] Visual Studio 2013 is Version number 12.0 of the product, and the new version, Visual Studio 2015 has the Version number 14.0 for the same reasons.
  • Roxio Toast went from version 12 to version 14, likely in an effort to skip the superstitions surrounding the number 13.
  • Corel's WordPerfect Office, version 13 is marketed as "X3" (Roman number 10 and "3"). The procedure has continued into the next version, X4. The same has happened with Corel's Graphic Suite (i.e. CorelDRAW, Corel Photo-Paint) as well as its video editing software "Video Studio".
  • Sybase skipped major versions 13 and 14 in its Adaptive Server Enterprise relational database product, moving from 12.5 to 15.0.
  • ABBYY Lingvo Dictionary uses numbering 12, x3 (14), x5 (15).
  • SUSE Linux Enterprise skipped version 13 and 14 after version 12 and directly released SLES 15 in July 2018.
  • In the mid-1990s, the rapidly growing CMMS, Maximo, moved from Maximo Series 3 directly to Series 5, skipping Series 4 due to that number's perceived marketing difficulties in the Chinese market, where the number 4 is associated with "death" (see tetraphobia). This did not stop Maximo Series 5 version 4.0 from being released. (The "Series" versioning has since been dropped, effectively resetting version numbers after Series 5 version 1.0's release.)

Geek culture

[edit]

Software examples

[edit]

Python

[edit]

The Python Software Foundation has published PEP 440 – Version Identification and Dependency Specification,[49] outlining their own flexible scheme, that defines an epoch segment, a release segment, pre-release and post-release segments and a development release segment.

TeX

[edit]

TeX has an idiosyncratic version numbering system, an unusual feature invented by its developer Donald Knuth. Since version 3.1, updates have been indicated by adding an extra digit at the end, so that the version number asymptotically approaches the number π, so 3.14 effectively means 3.2 in semantic versioning. (This is a form of unary numbering; the version number is the number of digits.) Since 2021, the version number has been 3.141592653. This is a reflection of TeX being 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.[50]

In a similar way, the version number of Metafont asymptotically approaches Euler's number, e.[50] As of February 2021, the version number is 2.71828182. Metafont was also devised by Donald Knuth as a companion to his TeX typesetting system.

Apple

[edit]

During the era of the classic Mac OS, minor version numbers rarely went beyond ".1". When they did, they usually jumped straight to ".5", suggesting the release was "more significant".[a] Thus, "8.5" was marketed as its own release, representing "Mac OS 8 and a half", and 8.6 effectively meant "8.5.1".

Mac OS X departed from this trend, in large part because "X" (the Roman numeral for 10) was in the name of the product. As a result, all versions of OS X began with the number 10. The first major release of OS X was given the version number 10.0, but the next major release was not 11.0. Instead, it was numbered 10.1, followed by 10.2, 10.3, and so on for each subsequent major release. Thus the 11th major version of OS X was labeled "10.10". Even though the "X" was dropped from the name as of macOS 10.12, this numbering scheme continued through macOS 10.15. Under the "X"-based versioning scheme, the third number (instead of the second) denoted a minor release, and additional updates below this level, as well as updates to a given major version of OS X coming after the release of a new major version, were titled Supplemental Updates.[51]

The Roman numeral X was concurrently leveraged for marketing purposes across multiple product lines. Both QuickTime and Final Cut Pro jumped from version 7 directly to version 10, QuickTime X and Final Cut Pro X. Like Mac OS X itself, the products were not upgrades to previous versions, but brand-new programs. As with OS X, major releases for these programs incremented the second digit and minor releases were denoted using a third digit. The "X" was dropped from Final Cut's name with the release of macOS 11.0 (see below), and QuickTime's branding became moot when the framework was deprecated in favor of AVFoundation in 2011 (the program for playing QuickTime video was only named QuickTime Player from the start).

Apple's next macOS release, provisionally numbered 10.16,[52] was officially announced as macOS 11 at WWDC in June 2020, and released in November 2020.[53] The following macOS version, macOS Monterey, was released in October 2021 and bumped its major version number to 12.[54]

In June 2025, Apple announced an unified versioning scheme, using the year next to the release date, similar to model years in vehicles. The versions that were released in the fall of 2025 are iOS 26, macOS 26, iPadOS 26, tvOS 26, watchOS 26 and visionOS 26.[55]

Microsoft Windows

[edit]

The Microsoft Windows operating system was first labelled with standard version numbers for Windows 1.01 through Windows 3.2. 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 (version 6.1). 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 versioning 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[56] and subsequent updates to the OS only incremented build number (which is date-based) and update build revision (UBR) number.

The successor of Windows 10, Windows 11, was released on October 5, 2021. Despite being named "11", the new Windows release did not bump its major version number to 11. Instead, it stayed at the same version number of 10.0, used by Windows 10.[57]

Non-software use

[edit]

Some computer file systems, such as the OpenVMS Filesystem, also keep versions for files. 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.

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

See also

[edit]

Notes

[edit]

References

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Software versioning

View on Grokipedia
from Grokipedia
Software versioning is the process of assigning unique identifiers, typically numbers or names, to distinct states or releases of computer software, enabling developers, users, and systems to track modifications, ensure compatibility, and manage updates across the software lifecycle. This practice distinguishes between incremental improvements, such as bug fixes or minor enhancements, and major overhauls that may introduce incompatibilities, thereby preventing issues like "" in interconnected software ecosystems. The origins of software versioning trace back to the early days of computing in the 1970s, when automated tools like the Source Code Control System (SCCS), developed at in 1972, began systematically tracking changes in to support collaborative development. Over time, versioning evolved alongside systems, with milestones including the release of (CVS) in 1986, which introduced branching and merging capabilities, in 2000, which enhanced centralized repositories, and the advent of distributed systems like in 2005, shifting to more flexible, decentralized models that improved scalability for large projects. These developments underscored versioning's role not just in recording changes but in facilitating atomic commits and multi-developer coordination without overwriting work. Among the most prominent standards today is Semantic Versioning (SemVer), a convention introduced to provide clear rules for incrementing version numbers in the format MAJOR.MINOR.PATCH, where major versions signal backward-incompatible changes, minor versions add backward-compatible features, and patch versions address bug fixes. Pre-release and build metadata can append identifiers like "-alpha" or "+build" to further denote development stages, ensuring released versions remain immutable to maintain trust in dependency management. Other schemes include calendar versioning (CalVer), which bases numbers on release dates (e.g., 2025.11.08), and simple sequential numbering, each chosen based on project needs for predictability or compatibility signaling. Effective versioning practices are integral to modern software engineering, supporting agile methodologies, open-source collaboration, and compliance with broader lifecycle standards like for software processes.

History

Early Practices

The practice of software versioning emerged in the mid-20th century as systems transitioned from hardware-centric designs to those incorporating software components, initially adopting simple numeric schemes to track updates and modifications. One of the earliest prominent examples was IBM's Operating System/360 (OS/360), announced alongside the System/360 hardware family in 1964 and first released in 1966, which employed sequential integer "Release" numbers—such as Release 1 in March 1966 and Release 6 in October 1966—to denote iterative improvements and bug fixes. These releases grew in scope, from 14 components in Release 1 to over 50 by Release 19 in 1970, reflecting the increasing complexity of mainframe software while maintaining a linear numbering system for straightforward identification of updates. Early software versioning was heavily influenced by hardware practices, particularly the sequential numbering used in systems prevalent from the onward. In these systems, software programs were stored and distributed as decks of s, where versions were managed through manual labeling or sequential deck numbering to distinguish updates, mirroring the model-based numbering of hardware components like IBM's earlier 1401 series. This approach ensured compatibility with , where card decks served as both and executable media, but it limited versioning to basic increments without automated tracking. By the late 1960s, more structured schemes appeared in academic and government-funded projects, with —one of the first operating systems, developed jointly by MIT, , and —introducing documented major.minor versioning. The system's initial boot occurred in December 1967 under version MR12.6f, followed by releases like MR6.5 by 1969, where the major number indicated significant architectural changes (e.g., support) and the minor number tracked incremental enhancements. This format, first operational in ' experimental phases from 1967 to 1969, allowed for finer-grained control over updates in a multi-user environment, setting a precedent for distinguishing compatibility-breaking changes from minor fixes. Versioning in the pre-personal computer era, spanning the 1950s to , faced significant challenges due to the absence of automated tools and the reliance on and manual processes. Developers distributed updates via punched cards, magnetic tapes, or paper , often requiring full recompilation and physical shipment, which delayed deployments and increased error risks in large-scale projects like OS/360. Without systems, tracking changes depended on handwritten logs or printed manuals, complicating collaboration among teams and leading to inconsistencies in multi-programmer environments. These limitations persisted until the , when early tools like the Source Code Control System (SCCS), developed at in 1972, began addressing them by providing automated delta-based storage for source code changes, but they underscored the era's emphasis on as the primary versioning mechanism.

Modern Developments

The open-source software movement, gaining momentum from the 1980s onward, significantly influenced software versioning practices by emphasizing collaborative development and the need for robust tracking mechanisms. Key early tools included the (RCS) in 1982, which improved on SCCS with reverse delta storage, and the (CVS) in 1986, which introduced branching and merging over networked repositories. Version control systems like (SVN), first released in 2000, introduced centralized repositories that supported branching and merging to manage parallel development streams, allowing teams to maintain version histories without overwriting changes. This was further advanced by , developed by in 2005 as a distributed version control system, which revolutionized versioning through lightweight branching, enabling non-linear development workflows and facilitating contributions from global open-source communities. A key milestone in modern versioning came with the formalization of Semantic Versioning (SemVer) in 2009 by , co-founder of , initially designed to provide predictable version numbering for open-source libraries like . SemVer's MAJOR.MINOR.PATCH format communicates compatibility intent—major increments for breaking changes, minor for backward-compatible features, and patch for fixes—reducing dependency conflicts in ecosystems like and Maven. Its integration with workflows allowed automated tagging of releases, streamlining the release process in collaborative environments. Standardization efforts in the 1990s by organizations like the IEEE provided foundational guidelines for versioning within broader . The IEEE Std 828-1990 outlined requirements for software configuration management plans, including version identification, control, and auditing to ensure across the software life cycle. Subsequent updates, such as those in ISO/IEC/IEEE 12207:2017, incorporated versioning into software life cycle processes, emphasizing to support maintenance, updates, and compliance in engineering practices. As of 2025, emerging trends leverage advanced technologies for more automated and secure versioning. AI-assisted tools in pipelines, as highlighted in the 2025 DORA State of AI-Assisted Software Development Report, are linked to higher software delivery throughput for high-performing teams. Additionally, -based approaches ensure immutable version histories; for instance, decentralized architectures using for systems provide tamper-proof audit trails, addressing vulnerabilities in traditional repositories by distributing commit logs across nodes.

Versioning Schemes

Sequence-Based Schemes

Sequence-based versioning schemes employ numeric sequences to identify software releases, typically structured as a series of integers separated by dots, such as major.minor.patch, to indicate the progression and significance of changes. These schemes allow developers to track evolution systematically, with each component incremented according to predefined rules that reflect the nature of updates, from minor fixes to major overhauls. The primary advantage lies in providing a clear for version and dependency , enabling automated tools to resolve compatible updates without manual intervention. The most common format is the three-part version number: major for incompatible changes, minor for backward-compatible feature additions, and patch for bug fixes that maintain compatibility. Under this structure, the major version increments when breaking changes occur, resetting minor and patch to zero; the minor increments for additions like new APIs without breaking existing ones, resetting patch to zero; and patch increments solely for fixes. This approach originated in conventions adopted by various open-source projects and has become a for many libraries and applications. Semantic Versioning (SemVer), formalized in version 2.0.0, refines this format as MAJOR.MINOR.PATCH, with explicit compatibility guarantees: versions within >=MAJOR.MINOR.PATCH <(MAJOR+1).0.0 are backward compatible, ensuring no breaking API changes in minor or patch releases. Pre-release versions append identifiers like -alpha or -beta (e.g., 1.0.0-alpha.1), treated as lower precedence than the main release, while build metadata uses + (e.g., 1.0.0+build.1), ignored for version comparison. Initial versions start at 0.y.z for unstable APIs, transitioning to 1.0.0 upon achieving stability. SemVer's rules promote predictable dependency resolution in ecosystems like or , reducing integration errors across projects. Variants of sequence-based schemes adapt the core format for specific needs. For instance, the Linux kernel historically used even minor versions (e.g., 2.4, 2.6) for stable releases focused on bug fixes, and odd minors (e.g., 2.5) for development branches introducing new features, allowing parallel maintenance of reliability and innovation. This even-odd distinction, while phased out in modern kernels favoring a single mainline with stable backports, exemplifies how sequences can signal release stability without strict semantic guarantees. In contrast, rolling release distributions like Arch Linux forgo distro-level version numbers entirely, instead applying upstream sequence-based versioning to individual packages with continuous increments and no periodic resets, ensuring users receive the latest stable updates via a unified package manager. Compatibility in sequence-based schemes varies by strictness: SemVer enforces rigorous API promises through its increment rules, facilitating automated compatibility checks in build systems. Looser implementations, such as arbitrary increments in internal tools without public semantics, prioritize simplicity over guarantees, often relying on changelogs for change assessment rather than version numbers alone. Sequence management typically involves resetting subordinate components upon major increments to maintain a monotonic progression, while separating build or metadata tags prevents pollution of the core sequence; multiple sub-sequences, like alpha or beta counters, may run parallel to the main one for testing phases.

Date-Based Schemes

Date-based versioning schemes, also known as calendar versioning or CalVer, assign version identifiers derived from release dates or timestamps rather than sequential numbers, prioritizing the temporal aspect of updates to reflect recency and schedule adherence. This approach is particularly suited to projects with predictable release cadences, such as operating systems or APIs that emphasize freshness over indicators. Common formats include YY.MM for biannual cycles, YYYY.MM.DD for more granular tracking, or YYYY-MM-DD for precise daily distinctions. For instance, employs a YY.MM format for its releases, with interim versions like 24.10 denoting the October 2024 release, allowing users to immediately gauge the software's age relative to support timelines. Similarly, Stripe's uses YYYY-MM-DD versioning, such as 2024-04-10, to mark updates without breaking changes, enabling developers to pin requests to specific dates for stability. In Python's packaging ecosystem, date-based segments are permitted under PEP 440, as in examples like 2012.4 for monthly releases, though core Python versions primarily follow semantic conventions; early beta snapshots occasionally incorporate YYYYMMDD for build identification. The primary advantages of date-based schemes lie in their inherent chronological ordering, which simplifies determining release freshness and aligns well with frequent-update scenarios in web and mobile ecosystems, ensuring automatic sorting by recency without manual intervention. They also enhance predictability for end-users and maintainers, as seen in Ubuntu's fixed nine-month support for interim releases or five-year LTS cycles tied directly to the version date. This temporal focus facilitates better integration with maintenance schedules, reducing confusion about version age in time-sensitive applications. However, these schemes present drawbacks, notably the challenge in conveying the scope or impact of changes between versions, requiring additional metadata like changelogs to assess compatibility—unlike numeric schemes that can signal major updates. In distributed global teams, coordinating across time zones can lead to non-monotonic version sequences if releases slip, potentially complicating dependency resolution or historical comparisons. For Android, while core OS versions use numeric identifiers, API levels like 34 map closely to release dates (e.g., in October 2023), illustrating a partial reliance on temporal mapping for ecosystem freshness without full date-based naming.

Hybrid and Other Schemes

Hybrid versioning schemes integrate elements from sequential numbering and date-based approaches to provide both chronological context and incremental tracking of changes. For instance, employs a four-part numeric structure—MAJOR.MINOR.BUILD.PATCH—to denote updates, where the major and minor components align with stable channel milestones, while build and patch numbers reflect iterative refinements in weekly release cycles. This combination allows developers to reference specific builds via numeric identifiers while associating them with precise release dates, facilitating precise and compatibility assessments in browser ecosystems. Non-numeric schemes utilize codenames or alphabetical identifiers to abstract versioning from strict numerical progression, often alongside base numeric versions for technical purposes. In Android, assigns dessert-themed codenames such as "" for version 8.0, which serve as internal development handles while the public-facing version remains numeric (e.g., 8.0), enabling teams to discuss features informally without implying maturity levels. Similarly, early releases transitioned from "NT 3.1" to "NT 4.0" using decimal increments that skipped intermediates like 3.2 for marketing alignment with consumer Windows versions, blending numeric simplicity with strategic non-sequential jumps. Unique systems deviate from conventional patterns to emphasize stability or protocol specificity. , developed by , employs an incremental decimal scheme starting from 3.0 and appending digits to approximate π (e.g., current version 3.141592653), ensuring by never resetting or introducing breaking changes post-freeze, with updates limited to bug fixes. In networking protocols, embeds a fixed version field value of 6 in its header to distinguish it from predecessors like IPv4, directly linking the identifier to the protocol's architectural standards without evolving versioning for subsequent iterations. As of 2025, emerging practices incorporate hash-based identifiers and adapted semantic tagging, particularly in distributed and contexts. Git commit hashes, such as abbreviated strings (e.g., "a1b2c3d"), are increasingly used as unique version markers for software releases, providing cryptographic immutability and without relying on sequential numbers, ideal for open-source projects where exact source states must be verifiable. In , semantic versioning schemes for models extend MAJOR.MINOR.PATCH formats to denote changes in training data, architecture, or performance metrics, with proposals for automated tagging based on model semantics to handle the non-deterministic nature of AI updates. These approaches prioritize and interoperability in dynamic environments like pipelines.

Pre-Release Indicators

Pre-release indicators are tags appended to software version numbers to denote versions that are not yet considered stable for general use, serving as markers for developmental stages such as internal testing, external beta trials, or final validation. These indicators, including , and release candidate (RC), signal potential instability and help manage user expectations by indicating that the software may contain bugs, incomplete features, or breaking changes. They are widely used in software release life cycles to facilitate iterative testing and feedback collection before achieving general availability. Common tags include "alpha" for early prototypes focused on basic functionality, "beta" for more mature builds inviting broader user input, and "RC" for near-final versions undergoing rigorous checks for regressions. In Semantic Versioning (SemVer), pre-release tags are appended after a hyphen to the normal version (e.g., MAJOR.MINOR.PATCH), using dot-separated identifiers like 1.0.0-alpha.1 or 1.0.0-rc.1, where the version indicates instability and lower precedence compared to the associated stable release. Similarly, Python's versioning standard (PEP 440) uses formats like X.YaN for alpha, X.YbN for beta, and X.YrcN for release candidates (e.g., 3.12a1), ordering them by phase and numerical suffix before the final release. These indicators are typically placed at the end of the base version string, such as 2.1-beta or 6.1-rc3 in the , where they integrate with sequence-based schemes by maintaining the core numbering while adding the tag for distinction. In systems, pre-releases often reside in dedicated es (e.g., a "beta" ) to isolate experimental changes from the mainline development. The purpose extends to enabling controlled feedback loops: alpha versions target developers for feature validation, engage select users for , and RCs focus on stability confirmation to minimize post-release issues. Transitions from pre-release to stable versions involve promoting the build by removing the indicator tag and, if necessary, incrementing the base version according to the adopted scheme—such as advancing from 1.0.0-rc.1 to 1.0.0 in SemVer upon general availability, ensuring backward compatibility as per the specification. In the Linux kernel process, after a series of RC releases (e.g., -rc1 to -rc8), the tag is dropped when regression reports subside, yielding the final stable kernel like 6.1. This promotion rule underscores the indicators' role in staging maturity without altering the semantic meaning of the core version components.

Technical Significance

In Development and Engineering

In software development, version control systems play a pivotal role in tracking changes and enabling collaborative engineering through structured branching strategies. One widely adopted model is the Gitflow workflow, which employs multiple branches to isolate development activities: the main branch holds stable release versions tagged with semantic numbers (e.g., v1.0.0), while the develop branch integrates ongoing features from short-lived feature branches created off develop. Release branches, forked from develop, allow final stabilization and versioning before merging back into both main and develop, ensuring that version increments align with release readiness. This approach minimizes disruptions by allowing parallel work on features without affecting production code. Additionally, tools like in Azure DevOps recommend feature branches for isolated tasks, with pull requests facilitating reviews and merges, where version diffs help resolve merge conflicts by highlighting changes between branch versions. Dependency management relies heavily on versioning to ensure and compatibility across components. In Node.js projects, uses semantic versioning (SemVer) in package.json files, where ranges like ^1.2.3 permit automatic updates to compatible minor and patch versions (up to but not including 2.0.0), balancing innovation with stability during development. Similarly, supports version ranges in POM files, such as [1.0,2.0) to include versions from 1.0 inclusive to 2.0 exclusive, enforced via plugins like the Enforcer to prevent mismatches that could break builds. These mechanisms allow engineers to specify flexible yet controlled dependencies, reducing manual intervention in multi-module projects. Versioning directly influences testing practices by enabling targeted validation of changes. Engineers create version-specific builds to conduct , verifying that new updates do not regress prior functionality, often through automated suites run against tagged releases. Ensuring is critical, as it confirms that the latest version processes inputs from earlier ones without errors, achieved via compatibility layers and tests on legacy environments to maintain ecosystem stability. Engineering best practices integrate versioning into continuous integration/continuous deployment (CI/CD) pipelines for automation and reliability. Semantic version increments can be automated based on commit history or conventional commits, as in AWS pipelines where tools analyze changes to bump major, minor, or patch numbers before deployment, streamlining release management. Error handling for version mismatches, such as dependency drift, involves locking versions in manifests and validating them during builds to catch incompatibilities early, preventing pipeline failures.

In Maintenance and Support

In software maintenance and support, versioning plays a crucial role in managing post-release updates, ensuring system stability, and guiding users through the lifecycle of a product. After initial deployment, maintainers use version increments to deliver patches that address bugs, vulnerabilities, and minor enhancements without disrupting core functionality. For instance, patch releases are typically denoted by incrementing the third component in a semantic versioning scheme, such as advancing from 1.0.0 to 1.0.1 for hotfixes. This approach allows organizations to issue targeted updates rapidly, as seen in the kernel's practice of releasing stable patches like 5.15.3 to fix regressions while preserving the base version's . End-of-support declarations are also tied to versioning, where maintainers announce a final patch level—such as version 2.7 for Python—after which no further updates are provided, prompting users to migrate to supported releases. Compatibility tracking is facilitated through version matrices that outline supported environments, operating systems, and dependencies for each release. These matrices help administrators verify that a given version, like 18.x, remains compatible with specific hardware or libraries over time. A prominent example is Python's support timeline, where the maintains a policy granting full bugfix support for 18 months and security fixes for up to five years per minor version, such as Python 3.9 receiving updates until October 2025. Similarly, Microsoft's .NET ecosystem uses version-specific compatibility lists to track runtime support across platforms, ensuring that applications built on .NET 6 can run on designated OS versions without unexpected failures. Support tiers further differentiate versioning strategies based on the intended longevity and update frequency. (LTS) versions, such as 20.04 LTS, receive extended maintenance—often five years of standard security updates plus optional extensions—making them suitable for enterprise environments requiring predictability. In contrast, short-cycle releases like 23.10 follow a nine-month support window, prioritizing rapid feature delivery over prolonged stability. This tiered approach is echoed in Android's versioning, where major releases like receive security patches for up to seven years on supported devices such as , following policies extended in 2023, without a formal LTS/non-LTS distinction. Deprecation warnings are integrated into release notes and changelogs, using version numbers to signal the removal of features in future iterations. For example, in the Rust programming language, deprecation attributes in version 1.70 notify developers of upcoming API changes, providing a grace period for migration before enforcement in subsequent releases like 1.80. These notices, often version-specific, enable proactive planning; Java's Oracle JDK, for instance, includes deprecation lists in release documentation for versions like 17, forecasting removals in JDK 21 to minimize disruption for long-running applications. By linking warnings to precise version milestones, maintainers foster smoother transitions and reduce technical debt in production systems.

Internal and Release Management

Internal versioning practices distinguish between public-facing version numbers and backend identifiers like build IDs or commit hashes, which enable precise tracking and debugging without exposing development details to users. Build IDs, often auto-generated during compilation, provide a unique sequential marker for each assembly, while Git commit hashes—such as 40-character SHA-1 strings—embed the exact codebase snapshot into executables or metadata. These internal markers facilitate rapid reproduction of issues in production logs, allowing engineers to correlate errors with specific code changes during post-mortem analysis. For example, in distributed systems, embedding commit hashes in application versions helps isolate faults across services without altering semantic versioning schemes visible to consumers. Release trains coordinate synchronized development and deployment cycles across multiple components, ensuring compatibility in complex software ecosystems through predefined schedules. This model groups features, fixes, and updates into periodic "trains" that depart on fixed timelines, minimizing integration delays. Google's Android platform exemplifies this with its Quarterly Platform Releases (QPRs), which align OS kernel updates, enhancements, and vendor integrations every three months to maintain ecosystem coherence. By enforcing version locks during the train window, teams avoid version drift, as seen in mobile apps where UI, backend, and third-party libraries must converge for builds. Staging processes progressively validate releases from internal alphas—early, unstable builds for developer testing—to canary deployments, where are gradually rolled out to subsets of production environments while syncing across modules. Internal focus on functionality verification within the team, often using provisional version tags to flag experimental states. Canary releases then introduce synced to a small user cohort, monitoring metrics like rates before broader . Synchronization across modules, such as ensuring dependent libraries share compatible version stamps, prevents runtime conflicts in modular architectures. This staged approach reduces risk, with tools automating version to maintain uniformity throughout the pipeline. Tools like Jira and Azure DevOps integrate version tagging directly into workflows, enabling teams to label issues, builds, and pipelines for streamlined release coordination. In Jira, versions act as milestones that aggregate epics and bugs, allowing drag-and-drop assignment and automated release note generation based on fix versions. Azure DevOps extends this with pipeline-integrated versioning, where release names incorporate variables like build numbers or dates (e.g., "Release-YYYYMMDD.$(Rev:.r)"), linking artifacts to commits for traceability. These features support internal tagging without impacting public releases, such as brief patches for maintenance.

Non-Technical Significance

Marketing Strategies

Software companies often employ version number inflation as a marketing tactic, incrementing major version numbers to portray incremental updates as groundbreaking advancements, thereby generating excitement and perceived value among consumers. This approach allows vendors to rebrand minor enhancements—such as bug fixes or small feature additions—as "major" releases, facilitating promotional campaigns that emphasize innovation and maturity. For example, jumped from to in 2015, using the version escalation to signal a fresh start and platform evolution in its marketing efforts. Similarly, the decision to name the subsequent release , despite technical continuities with , leveraged the numeric escalation to signal a fresh start and modern aesthetic, boosting advertising narratives around overhauls and hardware integration. Another key strategy involves building hype around the v1.0 , positioning it as the official transition to production-ready status to assure users of reliability and completeness. Vendors frequently delay this release to refine the product, using the announcement as a high-profile event to showcase stability and invite widespread . This tactic not only attracts early adopters but also reassures enterprise clients seeking dependable solutions, often accompanied by extensive materials highlighting the "" designation. In open-source contexts, reaching v1.0 serves as a critical signal of readiness, influencing trust and contribution rates. Version numbers are deeply integrated into branding efforts, appearing prominently in advertisements, product packaging, and press releases to evoke perceptions of progress and superiority. By opting for sequential jumps—like the shift from Windows 10 to 11—companies create visual and narrative freshness, differentiating their offerings in saturated markets and aligning with hardware partner promotions. This integration extends to taglines and visuals that tie the version to themes of renewal, such as Microsoft's campaigns portraying Windows 11 as a "new era" of computing. Consumer perceptions of software reliability are significantly influenced by version numbering, with research indicating that higher or strategically incremented numbers enhance appeal and trust. A study demonstrated that transitions from decimal to integer versions (e.g., from 2.4 to 3.0) amplify perceived improvement, leading to higher purchase intentions as users interpret the change as a substantial upgrade. This effect underscores how marketing leverages numerical psychology to imply superiority, with higher versions often equated to greater sophistication in user surveys.

Cultural and Symbolic Roles

In open-source communities, achieving version 1.0 often symbolizes a project's "graduation" from experimental development to maturity, marking the stabilization of its public and readiness for widespread adoption. This milestone is celebrated as a communal achievement, particularly in foundations like , where it signifies progression from incubator status to top-level project sustainability. For the , the release of version 1.0 in March 1994 represented a pivotal maturation of the open-source movement, transitioning from hobbyist efforts to a robust, production-ready system. Software versioning also intersects with cultural superstitions, influencing decisions in development teams. Some developers avoid version 13 due to , the widespread fear of the number 13 as unlucky, extending general societal taboos into technical practices. Releases on Fridays, especially , are often shunned as a superstition rooted in the belief that issues arising over the weekend would ruin leisure time, a tradition persisting despite modern pipelines. Within geek culture, software versioning inspires humor and memes that reflect the frustrations and quirks of development. The phrase "v0.9 forever" mocks perpetual beta projects that linger in pre-1.0 states, symbolizing endless without closure, a trope amplified in online developer forums. These elements foster a shared identity among programmers, where version numbers become punchlines for the iterative, imperfect nature of coding. Versioning carries political weight in government software, promoting transparency and accountability. Public sector projects in the increasingly adopt open-source practices with clear version numbering to enable auditing and public scrutiny of changes, building on the European Commission's Strategy 2020-2023 and its 2025 roadmap for digital autonomy. This approach ensures verifiable evolution of codebases, aligning with broader EU goals for digital sovereignty and reduced in administrative systems.

Practical Examples

Open-Source Software

In open-source software projects, versioning schemes often balance rapid development with stability to accommodate community contributions, as seen in the Linux kernel. Historically, the Linux kernel employed an odd/even numbering system for its minor versions, where odd numbers (e.g., 2.5.x) denoted development branches and even numbers (e.g., 2.6.x) indicated stable releases. This approach has evolved; since kernel version 2.6.13, the scheme shifted to a time-based model with major releases (e.g., 5.x or 6.x) occurring every 9-10 weeks, followed by stable branches derived from specific mainline versions. For instance, the 5.15 stable series, designated as a long-term support branch, starts at 5.15.0 and increments the patch level (e.g., 5.15.1, 5.15.2) for bug fixes and security updates backported from mainline, ensuring compatibility for enterprise distributions while the patch number resets to .0 upon branching from mainline. Python exemplifies a semantic versioning-inspired scheme tailored for open-source evolution, using a major.minor.patch format (e.g., 3.12.0) with annual feature releases approximately every 12-18 months. New features are introduced during the feature phase, followed by 18-24 months of bugfix support with releases every two months, and then security-only fixes for another 1-2 years, culminating in end-of-life (EOL) after five years from initial release. A notable example is Python 2.7, released in 2010, which reached EOL on January 1, 2020, after extended support due to its widespread adoption, marking the end of official bug fixes and security patches. This policy promotes timely upgrades while providing predictability for the community. The npm ecosystem, central to open-source development, highlights versioning challenges like "," where conflicting version requirements among transitive dependencies can lead to installation failures or inconsistent behavior across environments. To mitigate this, npm generates a package-lock. file during installation, which captures the exact versions, resolved dependency tree, and integrity hashes (e.g., SHA-512) of all installed packages, ensuring regardless of updates to the broader registry. This lockfile is committed to repositories, allowing teams to install identical dependency sets and avoiding mismatches that could arise from range-based specifications in package. (e.g., "^1.0.0"). Community governance plays a key role in open-source versioning decisions, as demonstrated by Python's Python Enhancement Proposal (PEP) process, which formalizes proposals for features, processes, and release schedules through community discussion and Steering Council approval. Release-specific PEPs, such as PEP 596 for Python 3.9, outline schedules, support durations, and deprecation policies, ensuring transparent decision-making that aligns with semantic versioning principles while addressing contributor feedback. This structured approach fosters collaboration, with accepted PEPs requiring implementation before integration into a version release.

Commercial Products

In commercial software products, versioning strategies are often shaped by business objectives such as revenue generation, , and compatibility assurance, influencing how updates are released and adopted. Windows exemplifies this through its major version jumps, which prioritize branding and market positioning over sequential numbering. For instance, skipped version 9 entirely when transitioning from to in 2014, a decision driven by branding considerations to signal a foundational shift toward a unified platform for PCs, tablets, and future devices like phones. This approach continued with the release of on October 5, 2021, marking another significant leap from without an intermediate version, emphasizing hardware-integrated features like enhanced and redesigns to drive hardware upgrades and lock-in. Rather than traditional service packs, Windows employs semi-annual feature updates (e.g., version 22H2 in 2022), which bundle new capabilities and security fixes, allowing to maintain a steady revenue stream from licensing while enforcing periodic system refreshes. Adobe's product lineup, particularly Photoshop, illustrates how subscription-based models integrate frequent versioning to encourage ongoing payments and rapid feature delivery. Since shifting to the Creative Cloud (CC) model in 2013, Adobe has adopted a year-based for major releases, such as Photoshop 2025 (internal version 26.x), which aligns updates with annual subscription cycles and enables seamless syncing. Minor updates occur monthly or bimonthly (e.g., 26.0 to 26.11), delivering incremental enhancements like AI-driven tools without requiring full reinstalls, a structure that ties user access to active subscriptions and reduces by limiting perpetual licenses. This versioning fosters a continuous , as subscribers must maintain payments to receive these updates, impacting users by necessitating hardware compatibility checks and workflow adjustments with each release. Enterprise software like 's S/4HANA demonstrates versioning tailored to large-scale business migrations, with historical yearly increments ensuring predictable upgrade paths. released annual versions such as S/4HANA 2021 and 2022, each introducing optimizations for in-memory computing and analytics while providing compatibility matrices to assess add-ons, custom code, and third-party integrations before upgrades. These matrices, detailed in official upgrade guides, outline support levels and migration requirements, helping organizations plan multi-year transitions without disrupting operations. Although shifted to a biennial cycle starting in 2023 for extended maintenance (seven years per release), the prior yearly cadence allowed businesses to align upgrades with fiscal planning, minimizing downtime costs estimated in the millions for global enterprises. These commercial practices often result in user impacts through enforced upgrade mechanisms, particularly in software-as-a-service (SaaS) environments. For example, (formerly Office 365) uses update channels like Monthly Enterprise, where feature updates roll out automatically every 30-90 days, locking older versions after a to enforce security compliance and subscription value. Administrators can defer updates temporarily via policy settings, but end-users face version locks that disable editing or compatibility with legacy files if not upgraded, driving adoption of cloud features and recurring fees while reducing support burdens for outdated installations. This model ensures perpetual innovation but can compel unplanned hardware investments or training, highlighting the tension between business efficiency and user autonomy in commercial versioning.

Unique Implementations

, developed by , employs a distinctive versioning scheme that began at version 0 in 1978 and has incrementally approached π (approximately 3.14159) through bug fixes without introducing new features since version 3.0 in 1990, symbolizing the software's long-term stability and Knuth's commitment to minimal changes. As of the latest release, stands at version 3.141592653, with corresponding updates to related tools like plain.tex at 3.1415926535, ensuring for decades of documents. This continuous, non-resetting progression deviates from typical semantic versioning by prioritizing mathematical elegance over conventional major-minor-patch structures, reflecting 's role as a foundational tool in . Apple's macOS versioning evolved from in its initial release as Mac OS X (version 10, or "X") in 2001, which marked a complete rewrite from prior Mac OS versions, to sequential for subsequent updates, such as (version 13) released in October 2022. Internally, macOS builds upon the open-source Darwin kernel, whose versions increment independently—for instance, corresponds to Darwin 22, continuing a pattern where Darwin versions align numerically with macOS major releases post-10.x (e.g., macOS 11 uses Darwin 20). This dual-layer approach allows Apple to maintain user-facing marketing names tied to California landmarks alongside technical kernel versioning, providing a that balances with engineering continuity. The HTTP protocol, standardized by the IETF, uses simple decimal versioning to denote evolutionary improvements, progressing from HTTP/1.1 (defined in RFC 2616, published in 1999 and obsoleted by RFC 7230–7235 in 2014) to HTTP/2.0 (RFC 7540, published in May 2015), which introduced binary framing and for enhanced . This scheme emphasizes compatibility across versions, with HTTP/2 retaining core semantics from 1.1 while optimizing transport, as evidenced by its adoption in over 50% of websites by 2019. Subsequent HTTP/3 (RFC 9114, 2022) further extends this decimal progression by shifting to over UDP, illustrating how protocol versioning facilitates standardized, incremental advancements in internet infrastructure without disrupting existing implementations. In video games, ' exemplifies episodic versioning through its shift from initial numeric releases like v1.0 in 2017 to a chapter-season model, where major overhauls reset the game world—such as the transition from Chapter 1 (seasons 1–10, 2017–2019) to Chapter 2 (seasons 1–8, 2019–2021)—allowing for thematic reboots and map redesigns while preserving core battle royale mechanics. Each season, typically lasting 2–3 months, introduces narrative arcs, new , and gameplay modes under chapter umbrellas, with the current Chapter 6 (as of 2025) continuing this structure to sustain long-term engagement without traditional linear version increments. This approach treats updates as serialized content episodes, differentiating it from one-time major releases in other titles by enabling ongoing, live-service evolution.

Extensions Beyond Software

In Hardware and Systems

In hardware and systems, software versioning adapts to the constraints of and embedded components, where updates must ensure stability across physical devices without disrupting core functionality. versions track incremental changes to low-level that interfaces directly with hardware, such as processors and controllers, often using simple alphanumeric schemes to denote revisions for bug fixes, security patches, or compatibility enhancements. This approach differs from by prioritizing non-disruptive updates that can be flashed onto chips via specialized tools or over-the-air mechanisms. A prominent example is and versioning in personal computers and servers. Manufacturers like employ an "A" prefix followed by two digits, starting with A00 for the initial release and incrementing to A01 or higher for subsequent updates; for instance, the transition from A00 to A01 in server often includes processor updates and mode improvements to address hardware-specific issues. Similarly, implementations follow comparable incrementing patterns to support modern boot processes and secure boot features, ensuring with existing hardware configurations. Embedded operating system kernels in devices, such as routers, blend date-based or major version identifiers with sequence numbers for precise tracking. In the DD-WRT project for custom router firmware based on Embedded Linux, versions combine a major release like v24 with a revision number from the SVN repository, denoted as r followed by a numeric identifier (e.g., r33006), facilitating identification of beta builds and incremental development changes. This hybrid scheme supports community-driven updates tailored to specific router hardware, balancing feature additions with stability for network devices. Internet of Things (IoT) systems introduce unique versioning challenges due to remote deployment and limited resources, particularly with over-the-air (OTA) updates that must minimize and risk of device failure. Tesla's vehicle exemplifies this, using a year-week format such as 2025.38 to denote releases that deliver features like enhanced visualizations and camera recordings via OTA, allowing seamless integration with hardware like sensors and infotainment systems. A key challenge is implementing reliable to previous versions if an update fails, often achieved through dual-bank (A/B) partitioning to switch back automatically and prevent bricking, as recommended for industrial IoT to maintain operational continuity. Hardware lock-ins further complicate versioning in integrated systems, where software components are tightly coupled to specific models. For graphics processing units (GPUs), ties versions to hardware architectures via branched releases; for example, the R470 branch supports legacy models like Kepler and Maxwell, but newer branches such as 550+ drop compatibility for these older GPUs, requiring users to remain on supported versions to avoid degradation or installation failures. This creates a form of version lock-in, where hardware model dictates the viable range, influencing upgrades and longevity.

In Standards and Documentation

In software engineering standards, versioning is integrated into configuration management processes to ensure the integrity, traceability, and controlled evolution of software products and associated artifacts. The ISO/IEC/IEEE 12207 standard on systems and software engineering—software life cycle processes defines configuration management as a core process that includes the identification of baselines, change control, status accounting, and audits for work products, where a "version" is explicitly described as an identified instance of an item that requires configuration management actions upon modification. This approach mandates that software items and their versions be uniquely identified, with changes tracked through formal procedures to maintain consistency across the life cycle stages, from development to maintenance. For documentation within these standards, versioning ensures alignment between software artifacts and their descriptive materials. The same ISO/IEC/IEEE 12207 outlines a software documentation management process that collects, maintains, and controls documentation, applying to version updates for items such as user manuals, test reports, and specifications. Similarly, the IEEE/ISO/IEC 26514 standard for systems and —design and development of information for users specifies requirements for producing versioned user documentation throughout the software life cycle, emphasizing and revision history to support maintenance and user comprehension, though it does not prescribe a specific . In broader quality management contexts, ISO 9001:2015 addresses versioning as part of documented information control under clause 7.5.3, requiring organizations to identify the current revision status of documents, protect them from unintended changes, and ensure availability of relevant versions at points of use. This applies to technical documentation in software projects, mandating approval, review, and update procedures that implicitly enforce versioning to prevent and support compliance. For instance, revision levels must be clearly marked, and obsolete versions retained only for specified purposes with safeguards against misuse. Standards bodies themselves exemplify versioning practices in their outputs. The (IETF) employs versioning in its (RFC) series, where protocol specifications evolve through numbered revisions (e.g., RFC 3253 defines versioning extensions for Web Distributed Authoring and Versioning, or , enabling document check-in/check-out and version history for collaborative authoring). Additionally, RFC 9393 establishes registries for software identification tags, including version schemes to standardize how software versions are denoted in network protocols and documentation. These mechanisms highlight versioning's role in maintaining and in standards documentation.

References

  1. https://www.techtarget.com/searchsoftwarequality/definition/versioning
  2. https://semver.org/
  3. https://tarynwritescode.hashnode.dev/a-history-of-version-control
  4. https://workos.com/blog/software-versioning-guide
  5. https://www.red-gate.com/blog/database-devops/history-of-version-control
  6. http://bitsavers.org/pdf/ibm/360/360_OS_Release_Dates.txt
  7. https://www.press.jhu.edu/books/title/9671/punched-card-systems-and-early-information-explosion-1880-1945
  8. https://ethw.org/Early_Punched_Card_Equipment%2C_1880_-_1951
  9. https://gunkies.org/wiki/Multics
  10. https://multicians.org/history.html
  11. https://octopus.com/devops/history/early-software-delivery-models/
  12. https://www.perforce.com/blog/vcs/what-svn
  13. https://git-scm.com/book/en/v2/Getting-Started-A-Short-History-of-Git
  14. https://standards.ieee.org/ieee/828/1215/
  15. https://cloud.google.com/resources/content/2025-dora-ai-assisted-software-development-report
  16. https://www.mdpi.com/2076-3417/13/5/3066
  17. https://www.linfo.org/kernel_version_numbering.html
  18. https://wiki.archlinux.org/title/Arch_Linux
  19. https://calver.org/
  20. https://calver.org/calendar_versioning.html
  21. https://ubuntu.com/about/release-cycle
  22. https://docs.stripe.com/api/versioning
  23. https://peps.python.org/pep-0440/
  24. https://aboutcode.org/2022/software-versioning/
  25. https://jacobtomlinson.dev/posts/2023/sometimes-i-regret-using-calver/
  26. https://www.chromium.org/developers/version-numbers/
  27. https://source.android.com/docs/setup/reference/build-numbers
  28. https://www.tug.org/whatis.html
  29. https://datatracker.ietf.org/doc/html/rfc8200
  30. https://www.sei.cmu.edu/blog/versioning-with-git-tags-and-conventional-commits/
  31. https://arxiv.org/html/2409.10472v3
  32. https://www.cs.uic.edu/~drmark/index_htm_files/PRIME.pdf
  33. https://www.kernel.org/doc/html/latest/process/2.Process.html
  34. https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow
  35. https://learn.microsoft.com/en-us/azure/devops/repos/git/git-branching-guidance?view=azure-devops
  36. https://docs.npmjs.com/about-semantic-versioning/
  37. https://maven.apache.org/enforcer/enforcer-rules/versionRanges.html
  38. https://learn.g2.com/backwards-compatibility
  39. https://testsigma.com/guides/compatibility-testing/
  40. https://aws.amazon.com/blogs/devops/using-semantic-versioning-to-simplify-release-management/
  41. https://www.browserstack.com/guide/ci-cd-challenges-and-solutions
  42. https://support.google.com/pixelphone/answer/4457705
  43. https://developers.redhat.com/articles/2022/11/14/3-ways-embed-commit-hash-go-programs
  44. https://www.hanselman.com/blog/adding-a-git-commit-hash-and-azure-devops-build-number-and-build-id-to-an-aspnet-website
  45. https://reproducible-builds.org/docs/version-information/
  46. https://developer.android.com/about/versions/15/release-notes
  47. https://proandroiddev.com/release-train-in-mobile-development-4c67954ab1b3
  48. https://martinfowler.com/bliki/CanaryRelease.html
  49. https://mcis.cs.queensu.ca/publications/2021/emse_armstrong.pdf
  50. https://www.atlassian.com/agile/tutorials/versions
  51. https://learn.microsoft.com/en-us/azure/devops/pipelines/release/?view=azure-devops
  52. https://learn.microsoft.com/en-us/answers/questions/5521945/understanding-the-way-windows-versions-its-operati
  53. https://www.zdnet.com/article/windows-11-its-one-louder-isnt-it/
  54. https://www.cloudbees.com/blog/best-practices-when-versioning-a-release
  55. https://www.zdnet.com/article/windows-12-faq-is-it-coming-in-2024-plus-some-surprising-predictions/
  56. https://www.researchgate.net/publication/324111567_Mind_the_Gap_How_Smaller_Numerical_Differences_Can_Increase_Product_Attractiveness
  57. https://softwareengineering.stackexchange.com/questions/440591/what-is-the-significance-of-reaching-major-version-1-0-0
  58. https://files.osf.io/v1/resources/wmj3q_v1/providers/osfstorage/66aabddc6a4172477b9b47d1?action=download&direct&version=1
  59. https://pvs-studio.com/en/blog/posts/1139/
  60. https://dev.to/ispmanager/10-it-traditions-and-superstitions-from-dobbys-harmful-spirit-to-a-cactus-on-the-desk-845
  61. https://tvtropes.org/pmwiki/pmwiki.php/Main/ObviousBeta
  62. https://commission.europa.eu/about/departments-and-executive-agencies/digital-services/open-source-software-strategy_en
  63. https://fermigier.com/blog/2025/07/european-commission-publishes-a-roadmap-on-open-source-software/
  64. https://www.sciencespo.fr/public/chaire-numerique/wp-content/uploads/2023/07/VO-Open-source.pdf
  65. https://www.kernel.org/category/releases.html
  66. https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
  67. https://devguide.python.org/versions/
  68. https://peps.python.org/pep-0373/
  69. https://npm.github.io/how-npm-works-docs/theory-and-design/dependency-hell.html
  70. https://docs.npmjs.com/files/package-lock.json
  71. https://peps.python.org/pep-0001/
  72. https://peps.python.org/topic/release/
  73. https://learn.microsoft.com/en-us/windows/release-health/windows11-release-information
  74. https://learn.microsoft.com/en-us/windows/deployment/update/waas-overview
  75. https://helpx.adobe.com/photoshop/kb/legacy-version-updates.html
  76. https://news.sap.com/2022/09/new-sap-s4hana-release-maintenance-strategy/
  77. https://help.sap.com/doc/760ce610a2af4174a329d2d8315378e2/2023/en-US/UPGR_OP2023.pdf
  78. https://learn.microsoft.com/en-us/microsoft-365-apps/updates/overview-update-channels
  79. https://learn.microsoft.com/en-us/microsoft-365-apps/updates/change-update-channels
  80. https://www-cs-faculty.stanford.edu/~knuth/abcde.html
  81. https://tug.org/whatis.html
  82. https://www.dell.com/support/home/en-us/drivers/driversdetails?driverid=nyvcd
  83. https://www.tesla.com/support/software-updates
  84. https://mender.io/resources/reports-and-guides/ota-updates-best-practices
  85. https://docs.nvidia.com/datacenter/tesla/pdf/NVIDIA_Data_Center_GPU_Driver_Release_Notes_510_v3.0.pdf
  86. https://wildart.github.io/MISG5020/standards/IEEE-12207-2008.pdf
  87. https://standards.ieee.org/ieee/26514/7467/
  88. https://datatracker.ietf.org/doc/html/rfc3253
  89. https://datatracker.ietf.org/doc/rfc9393/
Add your contribution
Related Hubs
User Avatar
No comments yet.