Software version：修訂間差異

2026年8月23日 (日) 18:12的最新修訂

Software versioning is the practice of assigning identifiers to distinct releases. This page records the scheme used on this wiki and the alternatives it was chosen over.

Scheme used here

Four sequences, major.minor.patch.build - the form used by the release logs on ASTAR, RTD1073, Netgem and Tiny6410, for example NTV350_Diag_1.0.3.4.

Field	Increment when
major	The interface changes in a way that breaks existing users.
minor	Features are added, but existing users are unaffected.
patch	Only defects are fixed.
build	A new build of otherwise identical source.

Any field that increments resets every field to its right.

Other schemes

Semantic versioning - three sequences with the same major/minor/patch

 rules made explicit and machine-checkable. See semver.org.

Date-based - 2015.04 or 20150401. Says when, not

 what changed; useful for rolling releases.

Year of release - marketing-facing, e.g. Windows 95. Carries no ordering

 information for a maintainer.

Degree of compatibility - some projects encode ABI compatibility in the

 major number so a linker can reason about it.

Practice

The version in the binary and the version in the tag must match. If they can

 disagree, they eventually will.

Never reuse a version number, even for a build that was never shipped.
An unreleased tree carries the next version with a suffix, not the last

 released version.

Reference

@@ 第1行： / 第1行： @@
-==Schemes==
+'''Software versioning''' is the practice of assigning identifiers to distinct
-A variety of version numbering schemes have been created to keep track of different versions of a piece of software. The ubiquity (the ability to be everywhere at the same time) of computers has also led to these schemes being used in contexts outside computing.
+releases. This page records the scheme used on this wiki and the alternatives it
+was chosen over.
-===Sequence-based identifiers===
+== Scheme used here ==
-[[Image:VersionNumbers.svg|right|Version number sequence|1000x500px]]
+Four sequences, '''major.minor.patch.build''' - the form used by the release logs
-In sequence-based software versioning schemes, each [[software release]] is assigned a unique identifier that consists of one or more sequences of numbers or letters. This is the extent of the commonality, however: schemes vary widely in areas such as the quantity of sequences, the attribution of meaning to individual sequences, and the means of incrementing the sequences.
+on [[ASTAR]], [[RTD1073]], [[Netgem]] and [[Tiny6410]], for example
+<code>NTV350_Diag_1.0.3.4</code>.
-====Change significance====
+{| class="wikitable"
-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.
+! Field !! Increment when
+|-
+| major || The interface changes in a way that breaks existing users.
+|-
+| minor || Features are added, but existing users are unaffected.
+|-
+| patch || Only defects are fixed.
+|-
+| build || A new build of otherwise identical source.
+|}
-For instance, in a scheme that uses a four-sequence identifier, the first sequence may be incremented only when the code is completely rewritten, while a change to the user interface or the documentation may only warrant a change to the fourth sequence.
+Any field that increments resets every field to its right.
-This practice permits users (or potential adopters) to evaluate how much real-world testing a given software release has undergone. If changes are made between, say, 1.3rc4 and the production release of 1.3, then that release, which asserts that it has had a production-grade level of testing in the real world, in fact contains changes which have not necessarily been tested in the real world ''at all''.{{Clarify|January 2010|date=January 2010}} This approach commonly permits the third level of numbering ("change"), but does not apply this level of rigor to changes in that number: 1.3.1, 1.3.2, 1.3.3, 1.3.4... 1.4b1, etc.{{Clarify|January 2010|date=January 2010}}
+== Other schemes ==
+* '''Semantic versioning''' - three sequences with the same major/minor/patch
+  rules made explicit and machine-checkable. See [https://semver.org/ semver.org].
+* '''Date-based''' - <code>2015.04</code> or <code>20150401</code>. Says when, not
+  what changed; useful for rolling releases.
+* '''Year of release''' - marketing-facing, e.g. Windows 95. Carries no ordering
+  information for a maintainer.
+* '''Degree of compatibility''' - some projects encode ABI compatibility in the
+  major number so a linker can reason about it.
-In principle, in subsequent releases, the ''major'' number is increased when there are significant jumps in functionality, the ''minor'' number is incremented when only minor features or significant fixes have been added, and the ''revision'' number is incremented when minor bugs are fixed. A typical product might use the numbers 0.9 (for beta software), 0.9.1, 0.9.2, 0.9.3, 1.0, 1.0.1, 1.0.2, 1.1, 1.1.1, 2.0, 2.0.1, 2.0.2, 2.1, 2.1.1, 2.1.2, 2.2, etc. Developers have at times jumped (for example) from version 5.0 to 5.5 to indicate that significant features have been added, but not enough to warrant incrementing the major version number, though this is [[Software_versioning#Separating_sequences|improper]].{{Clarify|January 2010|date=January 2010}}
+== Practice ==
+* The version in the binary and the version in the tag must match. If they can
+  disagree, they eventually will.
+* Never reuse a version number, even for a build that was never shipped.
+* An unreleased tree carries the next version with a suffix, not the last
+  released version.
-A different approach is to use the ''major'' and ''minor'' numbers, along with an alphanumeric string denoting the release type, i.e. "alpha", "beta" or "release candidate". A 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.0. If 1.0rc1 turns out to have bugs which must be fixed, it turns into 1.0rc2, and so on. The important characteristic of this approach is that the first version of a given level (beta, RC, production) ''must be identical'' to the last version of the release below it: you cannot make any changes at all from the last beta to the first RC, or from the last RC to production. If you do, you must roll out another release at that lower level.
+== Reference ==
+* [https://en.wikipedia.org/wiki/Software_versioning Software versioning - Wikipedia]
-However, since version numbers are human-generated, not computer-generated, there is nothing that prevents arbitrary changes that violate such guidelines: for example, the first sequence could be incremented between versions that differ by not even a single line of code, to give the (false) impression that very significant changes were made.
+* [https://semver.org/ Semantic Versioning]
-Other schemes impart meaning on individual sequences:
-:''<nowiki>major.minor[.build[.revision]]</nowiki>''
-or
-:''<nowiki>major.minor[.maintenance[.build]]</nowiki>''
-Again, in these examples, the definition of what constitutes a "major" as opposed to a "minor" change is entirely arbitrary and up to the author, as is what defines a "build", or how a "revision" differs from a "minor" change.
-In most proprietary software, the first released version of a software product has version 1.
-====Designating development stage====
-Some schemes use a zero in the first sequence to designate [[Software release life cycle#Alpha|alpha]] or [[Software release life cycle#Beta|beta]] status for releases that are not stable enough for general or practical deployment and are intended for testing or internal use only.
-It can be used in the third position:
-* 0 for alpha (status)
-* 1 for beta (status)
-* 2 for release candidate
-* 3 for (public) release
-For instance:
-* 1.2.0.1 instead of 1.2-a
-* 1.2.1.2 instead of 1.2-b2 (beta with some bug fixes)
-* 1.2.2.3 instead of 1.2-rc (release candidate)
-* 1.2.3.0 instead of 1.2-r (commercial distribution)
-* 1.2.3.5 instead of 1.2-r5 (commercial distribution with many bug fixes)
-====Separating sequences====
-When printed, the sequences may be separated with characters. The choice of characters and their usage varies by 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):
-* 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
-When a period is used to separate sequences, it does ''not'' represent a decimal point, and the sequences do ''not'' have positional significance. An identifier of ''2.5'', for instance, is not "two and a half" or "half way to version three", it is the ''fifth second-level revision of the second first-level revision''.
-====Number of sequences====
-There is sometimes a fourth, unpublished number which denotes the software build (as used by [[Microsoft]]). [[Adobe Flash]] notably publicly indicates a 4-part version, 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.
-====Incrementing sequences====
-There are two schools of thought regarding how numeric version numbers are incremented: Most [[free software]] packages treat numbers as a continuous stream, therefore a free software or open source product may have version numbers 1.7.0, 1.8.0, 1.8.1, 1.9.0, 1.10.0, 1.11.0, 1.11.1, 1.11.2, etc.  An example of such a software package is [[MediaWiki]].  However, many programs treat version numbers in another way, generally as decimal numbers, and may have version numbers such as 1.7, 1.8, 1.81, 1.82, 1.9, etc.  In software packages using this way of numbering 1.81 is the next minor version after 1.8. Maintenance releases (i.e. bug fixes only) would generally be denoted as 1.81a, 1.81b, etc.
-The standard [[GNU]] version numbering scheme is major.minor.revision, but [[emacs]] is notably 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#s-f-Version 5.6.12 Version]</ref>
-====Using negative numbers====
-There exist some projects that use negative version numbers.  One example is the [[smalleiffel]] 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|accessdate=2009-04-11|date=2000-02-28}}</ref>
-====Degree of compatibility====
-Some projects use the major version number to indicate incompatible releases. Two examples are Apache APR<ref name="apr">{{Cite web|url=http://apr.apache.org/versioning.html|title=Versioning Numbering Concepts - The Apache Portable Runtime Project|accessdate=2009-04-11}}</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=2004-09-14|accessdate=2009-04-11}}</ref>
-===Date===
-The [[Wine (software)|Wine]] project used a date versioning scheme, which uses the year followed by the month followed by the day of the release; for example, "Wine 20040505". Wine is now on a "standard" release track; the most current stable version (as of [[2010]]) is 1.2. [[Ubuntu Linux]] uses a similar versioning scheme—Ubuntu 10.04, for example, was released April 2010.
-When using dates in versioning, for instance, file names, it is common to use the ISO scheme<ref name="ISO Date">{{Cite web|url=http://www.cl.cam.ac.uk/~mgk25/iso-time.html|title=International standard date and time notation|author=Markus Kuhn|accessdate=2009-04-11|date=2004-12-19|publisher=[[University of Cambridge]]}}</ref>: YYYY-MM-DD, as this is easily string sorted to increasing/decreasing order. The hyphens are sometimes omitted.
-[[Microsoft Office]] build numbers are actually an encoded date.<ref name="ms">{{Cite web|url=http://www.codinghorror.com/blog/archives/000793.html|title=Coding Horror: What's In a Version Number, Anyway?|date=2007-02-15|accessdate=2009-04-11|author=Jeff Atwood}}</ref>
-===Year of release===
-Other examples, identifying versions by year ([[Adobe Illustrator]] 88, [[WordPerfect Office]] 2003).  Although when a date is used to denote version it is generally for marketing purposes, and an actual version number exists.  For example, [[Microsoft Windows 2000 Server]] is internally versioned as Windows NT 5.0 ("NT" being a reference to the original product name).
-===Alphanumeric codes=== <!-- explain? -->
-Examples:
-* [[Macromedia Flash]] MX
-* [[Adobe Photoshop]] CS2
-===TeX===
-[[TeX]] has an [[idiosyncratic]] version numbering system. Since version 3, updates have been indicated by adding an extra digit at the end, so that the version number [[asymptote|asymptotically]] approaches [[pi|π]]; this is a form of [[Unary numeral system|unary numbering]] – the version number is the number of digits. The current version is 3.1415926. This is a reflection of the fact that TeX is now very stable, and only minor updates are anticipated. TeX developer [[Donald Knuth]] has stated that the "absolutely final change (to be made after my death)" will be to change the version number to π, at which point all remaining bugs will become permanent features.<ref>Donald E. Knuth. [http://www.ntg.nl/maps/05/34.pdf ''The future of TeX and METAFONT''], NTG journal MAPS (1990), 489. Reprinted as chapter 30 of ''Digital Typography'', p. 571.</ref>
-In a similar way, the version number of [[METAFONT]] asymptotically approaches [[E (mathematical constant)|e]].
-===Apple===
-Apple has a formalised version number structure based around the NumVersion struct, which specifies a one- or two-digit major version, a one-digit minor version, a one-digit "bug" (i.e. revision) version, a stage indicator (drawn from the set development/prealpha, alpha, beta and final/release), and a one-byte (i.e. having values in the range 0–255) pre-release version, which is only used at stages prior to final. In writing these version numbers as strings, the convention is to omit any parts after the minor version whose value are zero (with "final" being considered the zero stage), thus writing 1.0.2b12, 1.0.2 (rather than 1.0.2f0), and 1.1 (rather than 1.1.0f0).
-===Other schemes===
-Some software producers use different schemes to denote releases of their software. For example, the [[Microsoft Windows]] operating system was first labelled with standard numerical version numbers ([[Windows 1.0]] through [[Windows 3.1x|Windows 3.11]]).  Later, Microsoft started using separate version names for marketing purposes, first using years ([[Windows 95]] (4.0), [[Windows 98]] (4.10), [[Windows 2000]] (5.0)), then using alphanumeric codes ([[Windows Me]] (4.90), [[Windows XP]] (5.1)), then using brand names ([[Windows Vista]] (6.0)).  With the release of [[Windows 7]] it appears that Microsoft has returned to using numerical version numbers, although the official version number for Windows 7 is 6.1<ref>Enter the "ver" command in Windows 7 command prompt</ref>.
-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.<!-- FIXME with more accurate information and actual Debian code names -->
 [[Category:Software Engineering]]