A software release life cycle is the sum of the stages of development and maturity for a piece of computer software: ranging from its initial development to its eventual release, and including updated versions of the released version to help improve software or fix software bugs still present in the software.
Usage of the "alpha/beta" test terminology originated at IBM. Similar terminologies for IBM's software development were used by people involved with IBM from at least the 1950s (and probably earlier). "A" test was the verification of a new product before the public announcement. "B" test was the verification before releasing the product to be manufactured. "C" test was the final test before the general availability of the product. As software became a significant part of IBM's offerings, the alpha test terminology was used to denote the pre-announcement test and the beta test was used to show product readiness for general availability. Martin Belsky, a manager on some of IBM's earlier software projects claimed to have invented the terminology. IBM dropped the alpha/beta terminology during the 1960s, but by then it had received fairly wide notice. The usage of "beta test" to refer to testing done by customers was not done in IBM. Rather, IBM used the term "field test".
Pre-alpha refers to all activities performed during the software project before formal testing. These activities can include requirements analysis, software design, software development, and unit testing. In typical open source development, there are several types of pre-alpha versions. Milestone versions include specific sets of functions and are released as soon as the functionality is complete.
The alpha phase of the release life cycle is the first phase to begin software testing (alpha is the first letter of the Greek alphabet, used as the number 1). In this phase, developers generally test the software using white-box techniques. Additional validation is then performed using black-box or gray-box techniques, by another testing team. Moving to black-box testing inside the organization is known as alpha release.
Alpha software can be unstable and could cause crashes or data loss. Alpha software may not contain all of the features that are planned for the final version. In general, external availability of alpha software is uncommon in proprietary software, while open source software often has publicly available alpha versions. The alpha phase usually ends with a feature freeze, indicating that no more features will be added to the software. At this time, the software is said to be feature complete.
Beta, named after the second letter of the Greek alphabet, is the software development phase following alpha. Software in the beta stage is also known as betaware. Beta phase generally begins when the software is feature complete but likely to contain a number of known or unknown bugs. Software in the beta phase will generally have many more bugs in it than completed software, speed or performance issues, and may still cause crashes or data loss. The focus of beta testing is reducing impacts to users, often incorporating usability testing. The process of delivering a beta version to the users is called beta release and this is typically the first time that the software is available outside of the organization that developed it. Software beta releases can either be public or private, depending on whether they openly available or only available to a limited audience. Beta version software is often useful for demonstrations and previews within an organization and to prospective customers. Some developers refer to this stage as a preview, preview release, prototype, technical preview / technology preview (TP), or early access.
Beta testers are people who actively report issues of beta software. They are usually customers or representatives of prospective customers of the organization that develops the software. Beta testers tend to volunteer their services free of charge but often receive versions of the product they test, discounts on the release version, or other incentives.
Some software is kept in perpetual beta, where new features and functionality are continually added to the software without establishing a final "stable" release.
As the Internet has facilitated rapid and inexpensive distribution of software, companies have begun to take a looser approach to use of the word "beta". 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, disparagingly called "perpetual beta". It noted that Gmail and Google News, for example, had been in beta for a long time although widely used; Google News did leave beta in January 2006, followed by Google Apps, including Gmail, in July 2009. This technique may allow a developer to delay offering full support and 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, or as a form of time-limited demo, or marketing technique. Since the introduction of Windows 8, Microsoft has called pre-release software as a "preview", rather than beta. All pre-release builds released through the Windows Insider Program launched in 2014 are termed "Insider Preview builds".
Developers may release either a closed beta also called private beta, or an open beta also called public beta; closed beta versions are released to a restricted group of individuals for a user test by invitation, while open beta testers are from a larger group, or anyone interested. Private beta could be suitable for the software that is capable to deliver value, but is not ready to be used by everyone either due to scaling issues, lack of documentation or still missing vital features. The testers report any bugs that they find, and sometimes suggest additional features they think should be available in the final version. Examples of a major public beta test include the following:
Open betas serve the dual purpose of demonstrating a product to potential consumers, and testing among an extremely wide user base likely to bring to light obscure errors that a much smaller testing team might not find.
A release candidate (RC), also known as "going silver", is a beta version with potential to be a final product, which is ready to release unless significant bugs emerge. In this stage of product stabilization, all product features have been designed, coded and tested through one or more beta cycles with no known showstopper-class bugs. A release is called code complete when the development team agrees that no entirely new source code will be added to this release. There could still be source code changes to fix defects, changes to documentation and data files, and peripheral code for test cases or utilities. Beta testers, if privately selected, will often be credited for using the release candidate as though it were a finished product. Beta testing is conducted in a client's or customer's location and to test the software from a user's perspective.
Once released, the software is generally known as a "stable release". The formal term often depends on the method of release: physical media, online release or a web application.
The term release to manufacturing (RTM), also known as "going gold", is a term used when a software product is ready to be delivered. This build may be digitally signed, allowing the end user to verify the integrity and authenticity of the software purchase. A copy of the RTM build known as the "gold master" or GM is sent for mass duplication if applicable. RTM precedes general availability (GA) when the product is released to the public.
It is typically used in certain retail mass-production software contexts—as opposed to a specialized software production or project in a commercial or government production and distribution—where the software is sold as part of a bundle in a related computer hardware sale and typically where the software and related hardware is ultimately to be available and sold on mass/public basis at retail stores to indicate that the software has met a defined quality level and is ready for mass retail distribution. RTM could also mean in other contexts that the software has been delivered or released to a client or customer for installation or distribution to the related hardware end user computers or machines. The term does not define the delivery mechanism or volume; it only states that the quality is sufficient for mass distribution. The deliverable from the engineering organization is frequently in the form of a golden master media used for duplication or to produce the image for the web.
General availability (GA) is the marketing stage at which all necessary commercialization activities have been completed and a software product is available for purchase, depending, however, on language, region, electronic vs. media availability. Commercialization activities could include security and compliance tests, as well as localization and worldwide availability. The time between RTM and GA can be from a week to months in some cases before a generally available release can be declared because of the time needed to complete all commercialization activities required by GA. At this stage, the software has "gone live".
Release to the web (RTW) or web release is a means of software delivery that utilizes the Internet for distribution. No physical media are produced in this type of release mechanism by the manufacturer. Web releases are becoming more common as Internet usage grows.
During its supported lifetime, software is sometimes subjected to service releases, patches or service packs, sometimes also called "interim releases". For example, Microsoft released three major service packs for the 32-bit editions of Windows XP and two service packs for the 64-bit editions. Such service releases contain a collection of updates, fixes, and enhancements, delivered in the form of a single installable package. They may also implement new features. Some software is released with the expectation of regular support. Classes of software that generally involve protracted support as the norm include anti-virus suites and massively multiplayer online games. A good example of a game that utilizes this process is Minecraft, an indie game developed by Mojang, which features regular "updates" featuring new content and bug fixes.
When software is no longer sold or supported, the product is said to have reached end-of-life, to be discontinued, retired, deprecated, abandoned, or obsolete, but user loyalty may continue its existence for some time, even long after its platform is obsolete—e.g., the Atari ST and Sinclair ZX Spectrum.
After the end-of-life date, the developer will usually not implement any new features, fix existing defects, bugs or vulnerabilities (known before that date or not) or provide any support for the product.
Alpha software generally barely runs and is missing major features like gameplay and complete levels.
Application retirement, also called application decommissioning and application sunsetting, is the practice of shutting down redundant or obsolete business applications while retaining access to the historical data. Legacy applications are often maintained solely to provide infrequent or sporadic access to data within the application database for regulatory or business purposes. With some organizations spending upwards of 75% of their application software budgets on ongoing maintenance, application retirement can deliver significant cost savings.
The act of application retirement usually involves migrating data from the legacy application database to another data repository or archive store that can be accessed independently using industry standard reporting or business intelligence tools. Application retirement allows IT departments within companies to reduce the software, hardware and resources required to manage legacy data.Beta phase
Beta phase may refer to:
the second phase in a software release life cycle: see Software release life cycle#Beta.
the second phase of pharmacokinetics: see Pharmacokinetics#Stages of Pharmacokinetic Processes.Code complete
Code complete can refer to:
A stage of the software release life cycle
Code Complete, a book on software development by Steve McConnellEnd-of-life (product)
"End-of-life" (EOL) is a term used with respect to a product supplied to customers, indicating that the product is in the end of its useful life (from the vendor's point of view), and a vendor stops marketing, selling, or rework sustaining it. (The vendor may simply intend to limit or end support for the product.) In the specific case of product sales, a vendor may employ the more specific term "end-of-sale" (EOS). The time-frame after the last production date depends on the product and relates to the expected product lifetime from a customer's point of view. Different lifetime examples include toys from fast food chains (weeks or months), mobile phones (3 years) and cars (10 years).Fedora Legacy
Fedora Legacy was a community-supported, open-source software project to freely distribute patches for critical software bugs and vulnerabilities to users of older versions of the Red Hat Linux and Fedora Core Linux distributions, after the publisher, Red Hat, ceased support.
Jesse Keating and David Eisenstein, two of the Fedora Legacy software maintainers, announced the discontinuation of the project on 31 December 2006.Fedora Legacy later cited the following as reasons for discontinuing the project: Not enough people contributing, testing, and deploying patches; not enough funds; waning interest in the project and new discussion about extending the software release life cycle of Fedora Core.Just before the discontinuation, Fedora Legacy was providing updates for Red Hat Linux versions 7.3 and 9, and Fedora Core 3 and 4. They ceased support for Fedora Core 1 and 2 when Red Hat published Fedora Core 6 Test 2. Earlier in 2006, Fedora Legacy announced their intention to provide updates for Red Hat 7.3 and 9 by the end of the year, and then to focus on Fedora Core 3 and 4.Gamma test
Gamma test can refer to:
software release life cycle
Gamma test (statistics)ISO/IEC 12207
ISO/IEC/IEEE 12207 Systems and software engineering – Software life cycle processes is an international standard for software lifecycle processes. First introduced in 1995, it aims to be a primary standard that defines all the processes required for developing and maintaining software systems, including the outcomes and/or activities of each process.Maintenance release
A maintenance release (also minor release or Maintenance Pack or MP) is a release of a product that does not add new features or content. For instance, in computer software, maintenance releases are typically intended to solve minor problems, typically "bugs" or security issues.Release
Release may refer to:
Film release, the public distribution of a film
Legal release, a legal instrument
News release, a communication directed at the news media
Release (ISUP), a code to identify and debug events in ISUP signaling
Release (music), one part of the A(ttack)D(ecay)S(sustain)R(release) envelope of a musical note
Release (software), a distribution of a computer software in the software release life cycle
Release (phonetics), the opening of the closure of a stop consonant
Release, a bridge in thirty-two-bar formRelease engineering
Release engineering, frequently abbreviated as RE or as the clipped compound Releng, is a sub-discipline in software engineering concerned with the compilation, assembly, and delivery of source code into finished products or other software components. Associated with the software release life cycle, it was said by Boris Debic of Google Inc. that release engineering is to software engineering as manufacturing is to an industrial process:
Release engineering is the difference between manufacturing software in small teams or startups and manufacturing software in an industrial way that is repeatable, gives predictable results,
and scales well. These industrial style practices not only contribute to the growth of a company but also are
key factors in enabling growth.
The importance of release engineering in enabling growth of a technology company has been repeatedly argued by John O'Duinn and Bram Adams. While it is not the goal of release engineering to encumber software development with a process overlay, it is often seen as a sign of organizational and developmental maturity.
Modern release engineering is concerned with several aspects of software production:
Being able to identify all of the source, tools, environment, and other components that make up a particular release.
The ability to integrate source, third party components, data, and deployment externals of a software system in order to guarantee operational stability.
The mission to provide a stable framework for development, deployment, audit and accountability for software components.
The ongoing research into what are the repercussions of modern software engineering practices on the productivity in the software cycle, e.g. continuous integration and push on green initiatives.Release engineering is often the integration hub for more complex software development teams, sitting at the cross between development, product management, quality assurance and other engineering efforts, also known as DevOps. Release engineering teams are often cast in the role of gatekeepers (e.g. at Facebook, Google, Microsoft) for certain critical products where their judgement forms a parallel line of responsibility and authority in relation to production releases (pushes).
Frequently, tracking of changes in a configuration management system or revision control system is part of the domain of the release engineer. The responsibility for creating and applying a version numbering scheme into software—and tracking that number back to the specific source files to which it applies—often falls onto the release engineer. Producing or improving automation in software production is usually a goal of the release engineer. Gathering, tracking, and supplying all the tools that are required to develop and build a particular piece of software may be a release engineering task, in order to reliably reproduce or maintain software years after its initial release to customers.
While most software engineers, or software developers, do many or all of the above as a course of their work, in larger organizations the specialty of the release engineer can be applied to coordinate disparate source trees, projects, teams, and components. This frees the developers to implement features in the software and also frees the quality assurance engineers to more broadly and deeply test the produced software.
The release engineer may provide software, services, or both to software engineering and software quality assurance teams. The software provided may build tools, assembly, or other reorganization scripts which take compilation output and place them into a pre-defined tree structure, and even to the authoring and creation of installers for use by test teams or by the ultimate consumer of the software. The services provided may include software build (compilation) automation, automated test integration, results reporting, and production of or preparation for software delivery systems—e.g., in the form of electronic media (CDs, DVDs) or electronic software distribution mechanisms.Service pack
In computing, a service pack comprises a collection of updates, fixes, or enhancements to a software program delivered in the form of a single installable package. Companies often release a service pack when the number of individual patches to a given program reaches a certain (arbitrary) limit, or the software release has shown to be stabilized with a limited number of remaining issues based on users' feedback and bug tracking such as Bugzilla. In large software applications such as office suites, operating systems, database software, or network management, it is not uncommon to have a service pack issued within the first year or two of a product's release. Installing a service pack is easier and less error-prone than installing many individual patches, even more so when updating multiple computers over a network, where service packs are common.
Service packs are usually numbered, and thus shortly referred to as SP1, SP2, SP3 etc. They may also bring, besides bug fixes, entirely new features, as is the case of SP2 of Windows XP (e.g. Windows Security Center), or SP3 and SP4 of the heavily database dependent Trainz 2009:World Builder edition.Software testing life cycle
Software testing life cycle may refer to:
Software development life cycle
Software release life cycle
|Deceptive and/or illicit|
|Software release life cycle|