Software release stages

---

Pre-alpha

Pre-alpha stage consists of the period of time from the start of the development phase until Alpha release (or any other stage that comes next, in case developers opt to have no Alpha release). Sometimes a build known as pre-alpha is issued before the release of an alpha or beta, as developers need to see how features work in action as the development process proceeds. 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 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. 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.

Pre-alpha

프리알파 단계는 개발 단계의 시작에서부터 알파 출시(또는 개발자들이 알파 출시를 건너뛰는 경우 다음으로 오게될 다른 어떤 단계)에 이르는 기간이다. 가끔은 프리알파로 알려진 빌드는 개발자들이 개발 프로세스 수행 단계의 행위로 기능들이 어떻게 동작하는지 확인할 필요가 있을 때, 알파나 베타 출시 전에 생성된다. 알파와 베타 버전과 대조적으로 프리알파는 기능이 완전하게 동작하지 않는다. 이것은 주로 소프트웨어 프로젝트 기간 내에 소프트웨어 테스팅 이전에 수행된 모든 활동들을 언급한다. 그런 활동들은 요구사항 분석, 소프트웨어 설계, 소프트웨어 개발과 단위 테스팅을 포함할 것이다.

일반적인 오프 소스 개발환경에서 몇가지 프리알파 버전의 형태가 있다. Milestone 버전은 특정한 기능 셋을 포함하고 최대한 기능이 완성된 상태로 출시된다. Nightly build는 일반적으로 자동적으로 리비전 관리 시스템에 의해 점검되고 보통 야간에 생성되는 버전을 말한다. 저런 버전들이 테스터가 가장 최근에 구현된 기능을 즉시 테스트 할 수 있고, 새로운 버그를 찾을 수 있도록 한다.

Alpha

The alpha build of the software is the build to the internal software testers, that is, people different from the software engineers, sometimes to the public, 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.

In software testing terminology alpha testing is done by the client in the presence of the tester or developers and the test environment is not open for the end user.

The Beta testing is done by the end user and the test environment is open.

Alpha

소프트웨어의 알파 빌드는 내부의 소프트웨어 테스터에 대한 빌드이다. 즉, 소프트웨어 엔지니어와 다른 사람들, 가끔은 대중이 될때도 있지만, 일반적으로 소프트웨어를 개발하는 조직이나 단체의 관점에서 내부자들이다. 시장에 출시할 때, 점점 더 많은 회사들이 그들의 알파테스팅 단계에서 외부의 고객들이나 협력 파트너를 고용하고 있다. 이는 알파 단계동안더 광범위한 사용성 테스팅을 할 수 있도록 한다

테스팅의 최초 단계에서 개발자들은 일반적으로 화이트 박스 기법을 사용하여 소프트웨어를 테스트한다. 그리고 나서 다른 전임된 테스팅 팀에 의한 추가적인 검증이 블랙박스나 그레이 박스 기법을 사용하여 수행된다. 가끔은 동시에 진행될 때도 있다. 조직 내부에서의 블랙 박스 테스팅으로 옮겨가는 것이 알파 출시로 알려져 있다.

소프트웨어 테스팅에서 알파 테스팅이란 용어는 테스터나 개발자들이 참석한 상태에서 고객에 의해 수행되고 테스트 환경은 최종사용자들에게 공개되지 않는다.

베타 테스팅은 최종사용자들에 의해 수행되고 테스트 환경은 공개된다.

Beta

베타는 개발의 알파 테스팅 단계를 통과한 소프트웨어의 별명이며 그것의 공식적인 출시전에 소프트웨어 테스팅을 위해 사용자들에게 전달된다. 어떤 베타 소프트웨어의 첫 번째 출시는 보통 마스터 베타로 언급된다. 연속적인 출시는 베타2, 베타3 등 으로 숫자가 할당된다. 베타 테스팅은 소프트웨어가 그런 사용자들이 소프트웨어에서 발견하는 오작동들이 개발자들에게 보고되고 수정될 수 있게 하기 위해 피드백을 제공하는 사용자들과 함께 사용성 테스팅을 겪도록 한다. 베타 소프트웨어는 불안정하고 충돌이나 데이터 손실을 야기할 수 도 있다.

하나의 베타 버전은 평가의 목적이나 실환경에서 블랙/그레이 박스 테스팅의 목적으로 소프트웨어를 개발하는 조직이나 단체 외부로 출시되는 첫 번째 버전이다. 사용자에게 베타 버전이 전달되는 과정은 베타 출시로 불린다. 베타 수준의 소프트웨어는 일반적으로 모든 기능을 포함한다. 하지만, 알려진 이슈와 심각성이 낮은 버그를 안고 있을 수 있다.

베타 버전의 사용자들은 베타 테스터로 불린다. 그들은 보통 소프트웨어를 개발한 조직의 고객이거나 잠재적인 고객이다. 그들은 무상 혹은 할인된 가격으로 소프트웨어를 제공받지만, 무료 테스터로써 활동한다.

베타 버전은 제품의 유지성, 시장에 메시지 전달, 제품의 생산가능성 그리고 전체적인 채널 흐름이나 채널 도달율을 테스트한다.

베 타 버전 소프트웨어는 내부적인 설명이나 고객들을 선정하기 위한 미리보기로써 유용할 것이다. 하지만 불안정하고 출시될 준비는 되지 않았다. 일부 개발자들은 이 단계를 프리뷰, 프로토타입, 테크니컬 프리뷰(TP) 또는 조기 접근으로 언급하기도 한다. 출시 생명 주기에서 알파 단계에 이은 두번째 중요한 단계로써, 그리스어 alphabet 의 두번째 글자인 beta 를 따서 명명되었다.

'Beta' is a nickname for software which has passed the alpha testing stage of development and has been released to users for software testing before its official release. The first release of any Beta software is usually referred to as the Master Beta, subsequent releases are assigned a number such as Beta 2, Beta 3 etc. Beta testing allows the software to undergo usability testing with users who provide feedback, so that any malfunctions these users find in the software can be reported to the developers and fixed. Beta software can be unstable and could cause crashes or data loss.

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 (CTPs) to beta testers 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". ^[1] 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 ^[2]. 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.

Origin of "alpha" and "beta"

The term beta test comes from an 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, by people or groups other than the developers, to verify that the hardware correctly performed the functions it was supposed to, and could be manufactured at scales necessary for the market. And finally, 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. 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.

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 of product stabilization (read QA cycle), all product features have been designed, coded and tested through one or more Alpha cycles with no known showstopper-class bugs.

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 other Greek letters) for versions that are substantially complete, but still under test, and omega or zenith 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.

RTM

The term “release to manufacturing” or “release to marketing” (both abbreviated RTM) - also known as "going gold" - is used to indicate that the software has met a defined quality level and is ready for mass distribution either by electronic means or by physical media. The term does NOT define the delivery mechanism, it only states that the quality is sufficient for mass distribution. The deliverable from the engineering organization is usually in the form of a gold master CD used for duplication or to produce the image for the web.

In most if not all cases, RTM happens prior to general availability (GA) where the product is released to the public.

GA

General availability (GA) is the point where all necessary commercialization activities have been completed and the software has been made available to the general market either via the web or physical media.

Commercialization activities could include but are not limited to the availability of media world wide via dispersed distribution centers, marketing collateral is completed and available in as many languages as deemed necessary for the target market, etc. 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.

Box copy

A box copy is a physical version of the final product, printed on a disc that is complete with disc graphic art. This term is used mostly by reviewers to differentiate from other forms of the released product (e.g., a downloaded copy, or a gold master burned on a generic disc). A box copy does not necessarily come enclosed in a box; it refers to the disc itself. In other words, we can say we get something tangible.

Web release

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

Production or live release

The production, live 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 live 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 live" means that the code has been completed and is ready for distribution. Other terms for the live version include: live master, live release, or live build. In some areas of software development the live release is referred to as a gold release; this seems to be confined mainly to game software.

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 are composed of three numbers, separated by a period. Between versions 1.0.0 and 2.6.x, stable releases had an even second number and unstable release an odd one. As of Linux 2.6.x, 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 other open and closed source projects.

End of life

End-of-life (EOL). 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." This is also true of the Netscape internet browser which stopped being supported in March 2008.