Editing Software versioning (section)

==Significance==

=== In software engineering ===
Version numbers are used in practical terms by the consumer, or [[consumer|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.<ref name="semver" /> 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 [[software framework|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).

Versioning is also a required practice to enable many schemes of patching and upgrading software, especially to automatically decide what and where to upgrade to.

===In technical support===
Version numbers allow people providing support to ascertain ''exactly'' which code a user is running, so that they can rule out bugs that have already been fixed as a cause of an issue, and the like. This is especially important when a program has a substantial user community, especially when that community is large enough that the people providing technical support are ''not'' the people who wrote the code. The semantic meaning<ref name="semver" /> of version.revision.change style numbering is also important to information technology staff, who often use it to determine how much attention and research they need to pay to a new release before deploying it in their facility. As a rule of thumb, the bigger the changes, the larger the chances that something might break (although examining the Changelog, if any, may reveal only superficial or irrelevant changes). This is one reason for some of the distaste expressed in the "drop the major release" approach taken by Asterisk et alia: now, staff must (or at least should) do a full regression test for every update.