Software release life cycle
From Wikipedia, the free encyclopedia
 |
This article or section is missing citations or needs footnotes. Using inline citations helps guard against copyright violations and factual inaccuracies. |
A software release is the distribution, whether public or private, of an initial or new and upgraded version of a computer software product. Each time a software program or system is changed, the software engineers and company doing the work decide on how to distribute the program or system, or changes to that program or system. Software patches are one method of distributing the changes, as are downloads and compact discs.
The software release life cycle is composed of different stages that describe the stability of a piece of software and the amount of development it requires before final release. Each major version of a product usually goes through a stage when new features are added, or the alpha stage; a stage when it is being actively debugged, or the beta stage; and finally a stage when all important bugs have been removed, or the stable stage. Intermediate stages may also be recognized. The stages may be formally announced and regulated by the project's developers, but sometimes the terms are used informally to describe the state of a product. Conventionally, code names are often used by many companies for versions prior to the release of the product, though the actual product and features are rarely secret.
Contents |
[edit] Software release stages
[edit] Pre-alpha
Sometimes a build known as pre-alpha is issued, before the release of an alpha or beta. In contrast to alpha and beta versions, the pre-alpha is not "feature complete". When it is used, it refers to all activities performed during the software project prior to software testing. These activities can include requirements analysis, software design, software development and unit testing.
In Open Source world, there are several types of pre-alpha versions. Milestone versions include specific sets of functionality and are released as soon as the functionality is complete. Nightly builds are versions that are usually automatically checked out from the revision control system and built, typically over night; these versions allow the testers to test the recently implemented functionality immediately, and find the new bugs.
[edit] Alpha
The alpha build of the software is the build delivered to the software testers, that is persons different from the software engineers, but usually internal to the organization or community that develops the software. In a rush to market, more and more companies are engaging external customers or value-chain partners in their alpha testing phase. This allows more extensive usability testing during the alpha phase.
In the first phase of testing, developers generally test the software using white box techniques. Additional validation is then performed using black box or grey box techniques, by another dedicated testing team, sometimes concurrently. Moving to black box testing inside the organization is known as alpha release.
[edit] Beta
A beta version is the first version released outside the organization or community that develops the software, for the purpose of evaluation or real-world black/grey-box testing. The process of delivering a beta version to the users is called beta release. Beta level software generally includes all features, but may also include known issues and bugs of a less serious variety.
The users of a beta version are called beta testers. They are usually customers or prospective customers of the organization that develops the software. They receive the software for free or for a reduced price, but act as free testers.
Beta versions test the supportability of the product, the go-to-market messaging (while recruiting Beta customers), the manufacturability of the product, and the overall channel flow or channel reach.
Beta version software is likely to be useful for internal demonstrations and previews to select customers, but unstable and not yet ready for release. Some developers refer to this stage as a preview, a prototype, a technical preview (TP) or as an early access. As the second major stage in the release lifecycle, following the alpha stage, it is named after the Greek letter beta, the second letter in the Greek alphabet.
Often this stage begins when the developers announce a feature freeze on the product, indicating that no more feature requirements will be accepted for this version of the product. Only software issues, or bugs and unimplemented features will be addressed.
Developers release either a closed beta or an open beta; closed beta versions are released to a select group of individuals for a user test, while open betas are to a larger community group, usually the general public. The testers report any bugs that they found and sometimes minor features they would like to see in the final version.
An example of a major public beta test was when Microsoft started releasing regular Windows Vista Community Technology Previews (CTP) to beta testers starting in January 2005. The first of these was build 5219. Subsequent CTPs introduced most of the planned features, as well as a number of changes to the user interface, based in large part on feedback from beta testers. Windows Vista was deemed feature complete with the release of build 5308 CTP, released on February 22, 2006, and much of the remainder of work between that build and the final release of the product focused on stability, performance, application and driver compatibility, and documentation.
When a beta becomes available to the general public it is often widely used by the technologically savvy and those familiar with previous versions as though it were the finished product. Usually developers of freeware or open-source betas release them to the general public while proprietary betas go to a relatively small group of testers. Recipients of highly proprietary betas may have to sign a non-disclosure agreement. A release is called feature complete when the product team agrees that functional requirements of the system are met and no new features will be put into the release, but significant software bugs may still exist. Companies with a formal software process will tend to enter the beta period with a list of known bugs that must be fixed to exit the beta period, and some companies make this list available to customers and testers.
As the Internet has allowed for rapid and inexpensive distribution of software, companies have begun to take a more flexible approach to use of the word "beta". Netscape Communications was infamous for releasing alpha level versions of its Netscape web browser to the public and calling them “beta” releases. In February 2005, ZDNet published an article about the recent phenomenon of a beta version often staying for years and being used as if it were in production-level [1]. It noted that Gmail and Google News, for example, had been in beta for a long period of time and were not expected to drop the beta status despite the fact that they were widely used; however, Google News did leave beta in January 2006. This technique may also allow a developer to delay offering full support and/or responsibility for remaining issues. In the context of Web 2.0, people even talk of perpetual betas to signify that some software is meant to stay in beta state. Also, "beta" is sometimes used to indicate something more like a release candidate such as the Halo 3 public beta.
[edit] Origin of 'alpha' and 'beta'
 |
This section does not cite any references or sources. Please improve this section by adding citations to reliable sources. Unverifiable material may be challenged and removed. (August 2007) |
The term beta test applied to software comes from an early IBM hardware product test convention dating back to punched card tabulating and sorting machines. Hardware first went through an alpha test for preliminary functionality and small scale manufacturing feasibility. Then came a beta test to verify that it actually correctly performed the functions it was supposed to and could be manufactured at scales necessary for the market, and then a c test to verify safety. With the advent of programmable computers and the first shareable software programs, IBM used the same terminology for testing software. Beta tests were conducted by people or groups other than the developers. As other companies began developing software for their own use, and for distribution to others, the terminology stuck and now is part of our common vocabulary.
[edit] Release candidate
The term release candidate refers to a version with potential to be a final product, ready to release unless fatal bugs emerge. In this stage, the product features all designed functionalities and no known showstopper-class bugs. At this phase the product is usually code complete.
Microsoft Corporation often uses the term release candidate. During the 1990s, Apple Inc. used the term "golden master" for its release candidates, and the final golden master was the general availability release. Other terms include gamma (and occasionally also delta, and perhaps even more Greek letters) for versions that are substantially complete, but still under test, and omega for final testing of versions that are believed to be bug-free, and may go into production at any time. (Gamma, delta, and omega are, respectively, the third, fourth, and last letters of the Greek alphabet.) Some users disparagingly refer to release candidates and even final "point oh" releases as "gamma test" software, suggesting that the developer has chosen to use its customers to test software that is not truly ready for general release. Often, beta testers, if privately selected, will be billed for using the release candidate as though it were a finished product.
A release is called code complete when the development team agrees that no entirely new source code will be added to this release. There may still be source code changes to fix defects. There may still be changes to documentation and data files, and to the code for test cases or utilities. New code may be added in a future release.
[edit] Gold or general availability release
The gold or general availability release version is the final version of a particular product. It is typically almost identical to the final release candidate, with only last-minute bugs fixed. A gold release is considered to be very stable and relatively bug-free with a quality suitable for wide distribution and use by end users. In commercial software releases, this version may also be signed (used to allow end-users to verify that code has not been modified since the release). The expression that a software product "has gone gold" means that the code has been completed and "is being mass-produced and will be for sale soon." Other terms for the version include gold master, golden master, “GM”, gold release, or gold build.
The term gold anecdotally refers to the use of "gold master disc" which was commonly used to send the final version to manufacturers who use it to create the mass-produced retail copies. It may in this context be a hold-over from music production. In some cases, however, the master disc is still actually made of gold, for both aesthetic appeal and resistance to corrosion.
[edit] RTM or RTW
Microsoft and others use the term "release to manufacturing" (RTM) to refer to this version (for commercial products, like Windows XP, as in, "Build 2600 is the Windows XP RTM release"), and "release to Web" (RTW) for freely downloadable products. Typically, RTW is at least one or two weeks before General Availability (GA) because the RTM version must be burned to disc and boxed etc.
[edit] Box copy
A box copy is the final product, printed on a disc that is included in the actual release, complete with disc graphic art. This term is used mostly by reviewers to differentiate from gold master discs. A box copy does not necessarily come enclosed in the actual boxed product - it refers to the disc itself.
[edit] Stable or unstable
In open source programming, version numbers or the terms stable and unstable commonly distinguish the stage of development. The term stable refers to a version of software that is substantially identical to a version that has been through enough real-world testing to reasonably assume there are no showstopper problems, or at least that any problems are known and documented. On the other hand, the term unstable does not necessarily mean that there are problems - rather, that enhancements or changes have been made to the software that have not undergone rigorous testing and that more changes are expected to be imminent. Users of such software are advised to use the stable version if it meets their needs, and to only use the unstable version if the new functionality is of interest that exceeds the risk that something might simply not work right.
In the Linux kernel, version numbers take the form of three numbers, separated by a decimal point. Prior to the 2.6.x series, an even second number was used to represent a stable release and an odd second number used to represent an unstable release. As of the 2.6.x series, the even or odd status of the second number no longer holds any significance. The practice of using even and odd numbers to indicate the stability of a release has been used by many other open and closed source projects.
[edit] End of life
Sometimes software companies stop selling or supporting their software products (e.g., not releasing new patches). At this point the product will be said to be in the status of "legacy", "vintage" or "end of life". For instance, on August 15, 2007, Apple announced that AppleWorks reached "end-of-life status". See also End-of-life (product).
[edit] See also
- Release engineering
- Rolling release
- Software maintenance
- Software testing
- Software versioning
- Release Management
