Software versioning

Software versioning

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.

oftware versioning 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.

Numeric

In the most common software versioning scheme, different major releases of the software each receive a unique numerical identifier. This is typically expressed as three numbers, separated by periods, such as version 2.4.13. One very commonly followed structure for these numbers is::"major.minor [.build [.revision] " or:"major.minor [.maintenance [.build] "

In most commercial software, the first released version of a software product has version 1.0. Numbers below 1 mean alpha or beta versions, i.e., versions for testing purposes or internal use, or versions that are not stable enough for general or practical deployment. 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 at times jump (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.

There is sometimes a fourth, unpublished number which denotes the software build (as used by Microsoft). Some companies also include the build date. Version numbers may also include letters and other characters, such as Lotus 1-2-3 Release 1a.

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.

This is to permit users (or potential adopters) to evaluate how much real-world testing a given build of code has actually 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". 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.

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, and may have version numbers such as 1.8, 1.9, 1.91, 1.92, etc. In software packages using this way of numbering 1.91 is the next minor version after 1.9. Maintenance releases (i.e. bug fixes only) would generally be denoted as 1.91a, 1.91b, etc.

There are also two variations in how the fourth number (build) is separated from the rest of the version string. In most software projects, versions go like 2.0.0.0, 2.0.0.1, 2.0.0.2, etc. (an example is Iceweasel/Firefox), where the build is separated by a dot just like the other numbers. However, a small minority of programs do not separate the build at all, resulting in strings like 1.5.7, 1.5.71, etc. An example of that peculiar version numbering is Umbrello UML designer and the 7zip compression utility.

There exist some projects that use negative version numbers. One example is the smalleiffel compiler which started from -1.0 and is counting upwards to 0.0, and is currently at -0.77. [http://www.advogato.org/article/40.html Advogato: Version numbering madness ] ]

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.

Some projects use the major version number to indicate incompatible releases. Two examples are Apache APR [http://apr.apache.org/versioning.html Versioning Numbering Concepts - The Apache Portable Runtime Project] ] and the FarCry CMS. [http://blog.daemon.com.au/archives/000276.html Daemonite: The science of version numbering ] ]

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 version as of June 6, 2008, is 1.0-rc4. Ubuntu Linux uses a similar versioning scheme—Ubuntu 8.04, for example, was released April 2008.

When using dates in versioning, for instance, file names, it is common to use the ISO scheme [http://www.cl.cam.ac.uk/~mgk25/iso-time.html International standard date and time notation ] ] : YYYY-MM-DD, as this is easily string sorted to increasing/decreasing order. The hyphens are usually omitted.

Microsoft's build number is actually an encoded date. [http://www.codinghorror.com/blog/archives/000793.html Coding Horror: What's In a Version Number, Anyway? ] ]

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 π. 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.

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), then by years (Windows 95, Windows 98, Windows 2000), after that using alphanumeric codes (Windows Me, Windows XP), and now using names (Windows Vista). 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.

Internal version numbers

Software may have an "internal" version number which differs from the version number shown in the product name (and which typically follows version numbering rules more consistently). J2SE 5.0, for example, has the internal version number of 1.5.0, and versions of Windows from 95 on have continued the standard numerical versions internally: Windows 95 is Windows 4.0, Windows 98 is 4.10, Windows Me is 4.90, Windows 2000 is NT 5.0, XP is Windows NT 5.1, 2003 is NT 5.2, and Vista is NT 6.0.

Pre-release versions

In conjunction with the various versioning schemes listed above, a system for denoting pre-release versions is generally used, as the program makes its way through the stages of the software release life cycle.Programs that are in an early stage are often called "alpha" software, after the first letter in the Greek alphabet. After they mature but are not yet ready for release, they may be called "beta" software, after the second letter in the Greek alphabet. Generally alpha software is tested by developers only, while beta software is distributed for community testing. Alpha- and beta-version software is often given numerical versions less than 1 (such as 0.9), to suggest their approach toward a public "1.0" release. However, if the pre-release version is for an existing software package (e.g. version 2.5), then an "a" or "alpha" may be appended to the version number. So the alpha version of the 2.5 release might be identified as 2.5a or 2.5.a.Software packages which are soon to be released as a particular version may carry that version tag followed by "rc-#", indicating the number of the release candidate. When the version is actually released, the "rc" tag disappears.

This can apparently cause trouble for some package managers, though. The Rivendell (software) radio automation package, for example, is about to have to release its first full production release package... v1.0.1, because if they called it v1.0.0, RPM would refuse to install it, thinking that version is *older* than "1.0.0rc2".

Modifications to the numeric system

Odd-numbered versions for development releases

Up until the 2.6.x series, the Linux kernel used odd minor version numbers to denote development releases and even minor version numbers to denote stable releases. For example, Linux 2.3 was a development family of the second major design of the Linux kernel, and Linux 2.4 was the stable release family that Linux 2.3 matured into. After the minor version number in the Linux kernel is the release number, in ascending order; for example, Linux 2.4.0 → Linux 2.4.22. Even further, a trivial version number was added to 2.6.8, making 2.6.8.1 which denoted a very minor change. This fourth number has been made standard since 2.6.11.1.

Apple

Apple had their own twist on this habit during the era of the classic MacOS: although there were minor releases, they rarely went beyond 1, and when they did, they twice jumped straight to 5, suggesting a change of magnitude intermediate between a major and minor release (thus, 8.5 really means 'eight and a half', and 8.6 is 'eight and a half point one'). The complete sequence of versions (neglecting revision releases) is 1.0, 1.1, 2.0, 2.1, 3.0, 3.2 (skipping 3.1), 4.0, 4.1, 5.0, 5.1, 6.0, 7.0, 7.1, 7.2, 7.5, 7.6, 8.0, 8.1, 8.5, 8.6, 9.0, 9.1, 9.2.

Mac OS X has bucked this trend, having gone more conventionally from 10.0 to 10.5, one minor release at a time. However, note that the 10.4.10 update bucks the previously-indicated approach of having a "one- or two-digit major version, a one-digit minor version, a one-digit 'bug' (i.e. revision) version…". The bug-fix value is not a decimal indicator, but is an incremental whole value; while it is not expected, there would be nothing preventing a distant-future "10.4.321" release.

Political and cultural significance of version numbers

Version 1.0 as a milestone

Commercial software developers often start at version 1 for the first release of a program and increment the major version number with each rewrite. This can mean that a program can reach version 3 within a few months of development, before it's even considered stable or reliable.

In contrast to this, the free-software community tends to use version 1.0 as a major milestone, indicating that the software is "complete", that it has all major features, and is considered reliable enough for general release.

In this scheme, the version number slowly approaches 1.0 as more and more bugs are fixed in preparation for the 1.0 release. The developers of MAME do not intend to release a version 1.0 of their emulator program. The argument is that it will never be truly "finished" because there will always be more arcade games. Version 0.99 was simply followed by version 0.100 (minor version 100 > 99).

To describe program history

Winamp released an entirely different architecture for version 3 of the program. Due to lack of backwards compatibility with plugins and other resources from the major version 2, a new version was issued that was compatible with both version 2 and 3. The new version was set to 5 (2+3), skipping version 4.

A similar thing happened with UnixWare 7, which was the combination of UnixWare 2 and OpenServer 5.

Keeping up with competitors

There is a common habit in the commercial software industry (usually, though not always, spurned by non-commercial programmers) 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 Word Perfect, 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 of Microsoft 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. ( [http://www.slackware.com/faq/do_faq.php?faq=general#0| Slackware FAQ] )

uperstition

*Current stable release of Microsoft Office has internal version number 12. The next version of the software will be version 14, due to superstitious reasons surrounding the number 13. [http://www.winsupersite.com/faq/office14.asp] Retrieved on September 12, 2007]
*Corel's WordPerfect Office, version 13 is marketed as "X3" (Roman number 10 and "3"). The procedure has continued into the next version, X4.

Overcoming perceived marketing difficulties

In the mid-1990s, the rapidly growing CMMS, Maximo, moved from Maximo Series 3 directly to Series 5, skipping Series 4 due to that number's perceived marketing difficulties in the Chinese market, where pronunciation of the number 4 () in Chinese rhymes with “death” or “failure”. This did not, however, stop Maximo Series 5 version 4.0 being released. (It should be noted the "Series" versioning has since been dropped, effectively resetting version numbers after Series 5 version 1.0's release.)

ignificance in software engineering

Version numbers are used in practical terms by the consumer, or client, by being able to compare their copy of the software product against another copy, such as the newest version released by the developer. For the programmer team or company, versioning is often used on a file-by-file basis, where individual parts or sectors of the software code are compared and contrasted with newer or older revisions, often in a collaborative version control system. There is no absolute and definite software version schema; it can often vary from software genre to genre, and is very commonly based on the programmer's personal preference.

ignificance in technical support

Version numbers allow people providing support to ascertain "exactly" what code a user is running, so that they know what bugs might affect a problem, and the like. This occurs 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.

Version numbers for files and documents

Some computer file systems, such as the OpenVMS Filesystem, also keep versions for files.

Versioning amongst documents is relatively similar to the routine used with computers and software engineering, where with each small change in the structure, contents, or conditions, the version number is incremented by 1, or a smaller or larger value, again depending on the personal preference of the author and the size or importance of changes made.

Version number ordering systems

Version numbers very quickly evolve from simple integers (1, 2, ...) to rational numbers (2.08, 2.09, 2.10)and then to non-numeric "numbers" such as 4:3.4.3-2. These complex version numbers are therefore better treated as character strings. Operating systems that include package management facilities (such as all non-trivial Linux or BSD distributions) will use a distribution-specific algorithm for comparing version numbers of different software packages. For example, the ordering algorithms of Red Hat and derived distributions differ to those of the Debian-like distributions.

As an example of surprising version number ordering implementation behavior, in Debian, leading zeroes are ignored in chunks, so that 5.0005 and 5.5 are considered as equal, and 5.5<5.0006. This can confuse users; string-matching tools may fail to find a given version number; and this can cause subtle bugs in package management if the programmers use string-indexed data structures such as version-number indexed hash tables.

In order to ease sorting, some software packages will represent each component of the "major.minor.release" scheme with a fixed width. Perl represents its version numbers as a floating-point number, for example, Perl's 5.8.7 release can also be represented as 5.008007. This allows a theoretical version of 5.8.10 to be represented as 5.008010. Other software packages will pack each segment into a fixed bit width, for example, 5.8.7 could be represented in 24 bits: ( 5 << 16 | 8 << 8 | 7 ). The floating-point scheme will break down if any segment of the version number exceeds 1,000; a packed-binary scheme employing 8 bits apiece after 256.

Use in other media

Software-style version numbers may be used in other media, playing on associations of version numbers with technology. Examples include:
* The "X-Men" Two-Disc Special Edition DVD was released as "X-Men 1.5".
* "Live Free or Die Hard" was released as "Die Hard 4.0" outside North America.
* The title of the computer game "Tron 2.0" implies that the motion picture (or previous arcade games) "Tron" was version 1.0.
* The rock band Garbage's second album is entitled "Version 2.0".
* David Gerrold's revised version of his novel "When HARLIE Was One" was subtitled "Release 2.0".
* The re-issue of the Mexican pop band Belanova's second album "Dulce Beat" was released as "Dulce Beat 2.0", wich includes a different version of "Te Quedas o Te Vas" and a second CD with acoustic versions, re-mixes and two music videos.
* Wizards of the Coast released "Dungeons & Dragons" 3.5 to demonstrate that significant rules changes had occurred, but not so significant that a new edition number was warranted. This has caused many to retroactively refer to the "Black Books" of 2nd Edition Advanced Dungeons & Dragons as version 2.5.
* Web 2.0 referring to the internet as used in collaborative projects such as wikis and social networking websites
* The Net 2.0 is the name of a sequel to the movie The Net
* The first series of The IT Crowd was Version 1.0; the second series was Version 2.0.

ee also

* Software release life cycle
* Revision control
* Product life cycle management
* Software engineering
* Maintenance release
* Point release

References

External links

* [http://www.codeproject.com/system/winvertable.asp Windows Version Numbers]
* [http://developer.apple.com/technotes/tn/tn1132.html TN 1132 - Version Territory] , the Apple technical note specifying the use of the NumVersion scheme
* [http://tldp.org/HOWTO/Software-Release-Practice-HOWTO/index.html Software Release Practice Howto]
* http://netrik.sourceforge.net/?versions.html
* http://www.everything2.com/index.pl?node_id=1128644
* http://pear.php.net/group/docs/20040226-vn.php
* http://openacs.org/doc/openacs-5-0-0/eng-standards-versioning.html
* http://wiki.eclipse.org/index.php/Version_Numbering
* http://www.linux.com/articles/45507
* http://blogs.ittoolbox.com/database/soup/archives/guide-to-postgresql-version-numbers-19177
* http://www.xfree86.org/4.1.0/Versions2.html
* http://www.phpbb.com/mods/documentation/appendix/versioning/index.php
* https://help.ubuntu.com/6.10/ubuntu/about-ubuntu/C/version-numbers.html


Wikimedia Foundation. 2010.

Игры ⚽ Поможем написать курсовую

Look at other dictionaries:

  • Software release life cycle —   A software release life cycle refers to the phases of development and maturity for a piece of computer software ranging from its initial development, to its eventual release, and updated versions of the released version to help improve… …   Wikipedia

  • Software house — A software house is a company whose primary products are composed of software, i.e., computer programs. Types of software houses There are a number of different types of software houses: *Large and well known companies such as Microsoft, Oracle… …   Wikipedia

  • versioning — ver‧sion‧ing [ˈvɜːʆnɪŋ ǁ ˈvɜːrʒ ] noun [uncountable] MARKETING when a company makes particular versions of products for different markets, customers etc: • versioning of computer software for individual clients • Any electronic versioning of the …   Financial and business terms

  • Versioning file system — A versioning file system is any computer file system which allows a computer file to exist in several versions at the same time. Thus it is a form of revision control. Most common versioning file systems keep a number of old copies of the file.… …   Wikipedia

  • Versioning — Eine Versionsverwaltung ist ein System, das zur Versionierung und Aktualisierung von Quelltexten verwendet wird. Hierzu werden Änderungen erfasst und alle Versionsstände der Dateien in einem Archiv mit Zeitstempel und Benutzerkennung gesichert.… …   Deutsch Wikipedia

  • Versioning — A business practice in which a company produces different models of the same product, and then charges different prices for each model. Versioning a product gives the consumer the option of purchasing a higher valued model for more money or a… …   Investment dictionary

  • Protocol versioning — Since digital communications protocols are controlled by software, protocol versioning generally follows software versioning standards …   Wikipedia

  • Ontology versioning — Contents 1 Introduction 1.1 cause of ontology change [1] 1.2 consequences of the change [1] 1.3 Current researches on the ontology versioning …   Wikipedia

  • Comparison of wiki software — The following tables compare general and technical information for a number of wiki software packages. Contents 1 General information 2 Target audience 3 Features 1 4 Features 2 …   Wikipedia

  • List of revision control software — This is a list of notable software for revision control. Distributed model In the distributed approach, each developer works directly with their own local repository, and changes are shared between repositories as a separate step. Open source *… …   Wikipedia

Share the article and excerpts

Direct link
Do a right-click on the link above
and select “Copy Link”