Software version
目錄
Schemes
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.
Sequence-based identifiers
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.
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.
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.
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 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
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 improper.模板:Clarify
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.
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.
Other schemes impart meaning on individual sequences:
- major.minor[.build[.revision]]
or
- major.minor[.maintenance[.build]]
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 alpha or 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, 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</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</ref> and the FarCry CMS.<ref name="farcry">模板:Cite web</ref>
Date
The 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</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</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
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 asymptotically approaches π; this is a form of 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. 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.
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.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.
