ABOUT SOFTWARE VERSIONS

Software versioning is the process of assigning either unique version names or unique version numbers to unique states of computer software. Within a given version number category (major, minor), these numbers are generally assigned in increasing order and correspond to new developments in the software. At a fine-grained level, revision control is often used for keeping track of incrementally different versions of electronic information, whether or not this information is actually computer software.

Schemes

A variety of version numbering schemes have been created to keep track of different versions of a piece of software. The ubiquity of computers has also led to these schemes being used in contexts outside computing.

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

[edit]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.^{[clarification needed]} 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.4.1, etc.^{[clarification needed]}

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 may choose to jump multiple minor versions at a time to indicate 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 limited to a single digit, as in Drupal version 7.12).

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". Asoftware 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 stableenough) == 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.

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.

[edit]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 (final) release

For instance:

• 1.2.0.1 instead of 1.2-a1
• 1.2.1.2 instead of 1.2-b2 (beta with some bug fixes)
• 1.2.2.3 instead of 1.2-rc3 (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)

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

Keeping up with competitors

There is a common habit in the proprietary software industry to make major jumps in numeric major or minor version numbers for reasons which do not seem (to many members of the program's audience) to merit the "marketing" version numbers.

This can be seen in several Microsoft and America Online products, as well as Sun Solaris and Java Virtual Machine numbering, SCO Unix version numbers, and Corel WordPerfect, as well as the filePro DB/RAD programming package, which went from 2.0 to 3.0 to 4.0 to 4.1 to 4.5 to 4.8 to 5.0, and is about to go to 5.6, with no intervening release. A slightly different version can be seen in AOL's PC client software, which tends to have only major releases (5.0, 6.0, 7.0, etc.). Likewise, Microsoft Access jumped from version 2.0 to version 7.0, to match the version number ofMicrosoft Word.

Microsoft has also been the target of 'catch-up' versioning, with the Netscape browser 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.

Sun's Java has at times had a hybrid system, where the actual version number has always been 1.x but three times 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 ("Java 5")
• Java 1.6.0 ("Java 6")

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.

Another example of keeping up with competitors is when Slackware Linux jumped from version 4 to version 7 in 1999.^[13]

A similar jump has recently taken place with the Asterisk open-source PBX construction kit, whose project leads announced that the current version 1.8.x will soon be followed by version 10, which will be followed by version 11, and then 12, and so forth, presumably dropping the other components (and their useful semantic significance) entirely. This change, though, does not seem to be motivated by 'keeping up with competition'.


SOURCE: http://en.wikipedia.org/wiki/Software_versioning