Open main menu
Home
Random
Recent changes
Special pages
Community portal
Preferences
About Wikipedia
Disclaimers
Incubator escapee wiki
Search
User menu
Talk
Dark mode
Contributions
Create account
Log in
Editing
Software versioning
(section)
Warning:
You are not logged in. Your IP address will be publicly visible if you make any edits. If you
log in
or
create an account
, your edits will be attributed to your username, along with other benefits.
Anti-spam check. Do
not
fill this in!
===Sequence-based identifiers=== [[File:VersionNumbers.svg|thumb|upright=0.5|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.<ref>{{Cite web |title=PEP 440 β Version Identification and Dependency Specification {{!}} peps.python.org |url=https://peps.python.org/pep-0440/ |access-date=2023-04-19 |website=peps.python.org}}</ref> This is the extent of the commonality; schemes vary widely in areas such as the number of sequences, the attribution of meaning to individual sequences, and the means of incrementing the sequences. ==== Change significance ==== In some schemes, sequence-based identifiers are used to convey the significance of changes between releases. Changes are classified by significance level, and the decision of which sequence to change between releases is based on the significance of the changes from the previous release, whereby the first sequence is changed for the most significant changes, and changes to sequences after the first represent changes of decreasing significance. Depending on the scheme, significance may be assessed by lines of code changed, function points added or removed, the potential impact on customers in terms of work required to adopt a new version, risk of bugs or undeclared breaking changes, degree of changes in visual layout, the number of new features, or almost anything the product developers or marketers deem to be significant, including marketing desire to stress the "relative goodness" of the new version. <!-- [[Semantic versioning]] and [[SemVer]] redirect here -->==== Semantic versioning ==== [[File:Semver.jpg|thumb|Semantic versioning three-part version number]] '''{{Visible anchor|Semantic versioning}}''' (aka '''SemVer''')<ref name="semver"> Preston-Werner, Tom (2013). [https://semver.org/ Semantic Versioning] 2.0.0. Creative Commons. Retrieved from https://semver.org/spec/v2.0.0.html. </ref> is a widely-adopted version scheme<ref>{{cite book|last1=Lam|first1=Patrick|last2=Dietrich|first2=Jens|last3=Pearce|first3=David J.|date=August 16, 2020|title=Proceedings of the 2020 ACM SIGPLAN International Symposium on New Ideas, New Paradigms, and Reflections on Programming and Software|chapter=Putting the semantics into semantic versioning |pages=157β179 |doi=10.1145/3426428.3426922 |arxiv=2008.07069|isbn=9781450381789 |s2cid=221139849 }}</ref> 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. 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 (software)|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 (which, 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: :''<nowiki>major.minor[.build[.revision]]</nowiki>'' (example: ''1.2.12.102'') :''<nowiki>major.minor[.maintenance[.build]]</nowiki>'' (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 Solaris and [[Linux]] may use the ''<nowiki>current.revision.age</nowiki>'' format where:<ref name="libinterface">{{cite web|url=http://static.usenix.org/publications/library/proceedings/als00/2000papers/papers/full_papers/browndavid/browndavid_html/|title=Library Interface Versioning in Solaris and Linux}}</ref><ref>{{cite web |title=Libtool's versioning system |url=https://www.gnu.org/software/libtool/manual/libtool.html#Versioning |website=Libtool documentation}}</ref> :''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 (book)#Revised edition|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|date=December 2020}} ==== Degree of compatibility ==== Some projects use the major version number to indicate incompatible releases. Two examples are [[Apache Portable Runtime]] (APR)<ref name="apr">{{cite web|url=http://apr.apache.org/versioning.html|title=Versioning Numbering Concepts β The Apache Portable Runtime Project|access-date=April 11, 2009}}</ref> and the FarCry CMS.<ref name="farcry">{{cite web|url=http://blog.daemon.com.au/archives/000276.html|title=Daemonite: The science of version numbering|date=September 14, 2004|access-date=April 11, 2009}}</ref> Often programmers write new software to be [[backward compatible]], i.e., the new software is designed to interact correctly with older versions of the software (using old protocols and file formats) and the most recent version (using the latest protocols and file formats). 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.<ref> Frank Kyne, Bert de Beer, Luis Martinez, Harriet Morril, Miha Petric, David Viguers, Suzi Wendler. [https://books.google.com/books?id=UxjCAgAAQBAJ "System z Parallel Sysplex Best Practices"]. 2011. p. 6. </ref> Often [[packet header]]s and [[file format#Internal metadata|file format]] include a version number β sometimes the same as the version number of the software that wrote it; other times a "protocol version number" independent of the software version number. The code to handle old [[deprecated]] protocols and file formats is often seen as [[cruft]]. ==== Designating development stage ==== Software in the experimental stage ([[Alpha test|alpha]] or [[Betaware|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.<ref name="semver" /> A number of schemes are used to denote the status of a newer release: * ''Alphanumeric suffix'' is a common scheme adopted by semantic versioning.<ref name="semver" /> 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]]. {| class="wikitable" |+ Comparison of development stage indicators |- ! Development<br>stage !! Semantic<br>versioning !! Numeric<br>status !! Numeric<br>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. ==== Incrementing sequences ==== There are two schools of thought regarding how numeric version numbers are incremented. 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]], [[Timeline of DOS operating systems|DOS]], and [[Timeline of Microsoft Windows|Microsoft Windows]], but even in the 2000s have been for example used by [[Opera (web browser)|Opera]]<ref>{{cite web|title=Opera Changelogs for Windows|publisher=[[Opera Software]]|year=2014|access-date=November 6, 2014|url=http://www.opera.com/docs/changelogs/windows/}}</ref> and [[Movable Type]].<ref>{{cite web|title=Home|work=Movable Type Documentation Wiki|date=June 25, 2013|access-date=November 6, 2014|url=https://github.com/movabletype/Documentation/wiki/Home/4aa709ba079523d7a64cab4a86650f8a8b7a9121}}</ref> 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,<ref>{{cite web|url=https://www.gnu.org/prep/standards/html_node/Releases.html#index-version-numbers_002c-for-releases |title=GNU Coding Standards: Releases |publisher=[[GNU Project]] |date=May 13, 2014 |access-date=May 25, 2014 |quote=You should identify each release with a pair of version numbers, a major version and a minor. We have no objection to using more than two numbers, but it is very unlikely that you really need them.}}</ref> 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.<ref name="advogato"/> Similarly, [[Debian]] package numbers are prefixed with an optional "epoch", which is used to allow the versioning scheme to be changed.<ref>Debian Policy Manual, [http://www.debian.org/doc/debian-policy/ch-controlfields.html#version 5.6.12 Version]</ref> ==== Resetting ==== 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.<ref>{{cite web |url=https://minecraft.wiki/w/Java_Edition_version_history |title=Java Edition version history |work=Minecraft Wiki |access-date=24 September 2023 |language=en}}</ref> ==== Separating sequences ==== When printed, the sequences may be separated with characters. The choice of characters and their usage varies by the scheme. The following list shows hypothetical examples of separation schemes for the same release (the thirteenth third-level revision to the fourth second-level revision to the second first-level revision):{{or inline|date=December 2020}} * A scheme may use the same character between all sequences: 2.4.13, 2/4/13, 2-4-13 * A scheme choice of which sequences to separate may be inconsistent, separating some sequences but not others: 2.413 * A scheme's choice of characters may be inconsistent within the same identifier: 2.4_13 (for instance, ''[[Minecraft]]'' Beta incremented from 1.7 to 1.7_01 to 1.7.2) When a period is used to separate sequences, it ''may'' or ''may not'' represent a decimal pointβsee "[[#Incrementing sequences|Incrementing sequences]]" section for various interpretation styles. ==== Number of sequences ====<!-- This looks more like a part of another section. Somebody care to merge? --> There is sometimes a fourth, unpublished number which denotes the [[software build]] (as used by [[Microsoft]]). [[Adobe Flash]] is a notable case where a four-part version number is indicated publicly, as in 10.1.53.64. Some companies also include the build date. Version numbers may also include letters and other characters, such as [[Lotus 1-2-3]] Release 1a. ==== Negative numbers ==== Some projects use negative version numbers. One example is the [[SmartEiffel]] compiler which started from β1.0 and counted upwards to 0.0.<ref name="advogato">{{cite web|url=http://www.advogato.org/article/40.html|title=Advogato: Version numbering madness|access-date=April 11, 2009|date=February 28, 2000}}</ref>
Edit summary
(Briefly describe your changes)
By publishing changes, you agree to the
Terms of Use
, and you irrevocably agree to release your contribution under the
CC BY-SA 4.0 License
and the
GFDL
. You agree that a hyperlink or URL is sufficient attribution under the Creative Commons license.
Cancel
Editing help
(opens in new window)