Software release life cycle

In the process of software development, the provided software goes through different stages of development, which are also considered as milestones.

The stages of development are: pre - alpha alpha → → → Beta Release Candidate → Release

After reaching the final state is the cycle begins again by resuming work on a new version of the software from scratch. Depending on the size of the software project and the process model are omitted some stages or be merged.

Pre- alpha version

Generally ( from Latin pre, before (standing) ' and the Greek letters Alpha, the first state '), any state of development before the first alpha release than a pre- alpha version are referred to. Often such a version is used when a reasonably complete module of the software will be presented. Another name is the developer preview (from English developer preview).

Alpha version

The first to test by strangers (not the actual developers) specific version of a computer program is often called alpha version. Although the term is not precisely defined, usually an alpha version already contains the basic components of the software product - but it is almost imperative that in later versions of the functions will be expanded.

In particular, alpha versions contain mostly bug in extent or quantity, which make them unsuitable for production use.

Beta version

A beta version is an unfinished version of a computer program.

Frequently beta versions are the first versions of a program, which will be published by the manufacturer for testing. As a Beta tester is referred to in general or to the first independent third-party or anonymous testers and users.

The term is not precisely defined, as a rule of thumb for delimiting a beta version from other versions, therefore, is usually considered that although implements all the essential functions of the program, but have not been fully tested and the program probably many more, also contains serious errors that do not make productive use recommended.

Beta versions of programs are usually at the 0 as the major version number - this variant is of course only for the beta versions before the first finished version (1.0 ) - or the suffix beta to recognize.

The benefits of beta testing is that errors that typically occur only in practice, can be detected, such as conflicts with other programs or problems with certain hardware components, even before the release of the program and eliminated or at least documented.

Beta versions are not normally sold in the same way as release candidates or finished versions. The following options are used:

• In ( un) periodically defined snapshots ( current development states) are generated from the source control system and en bloc offered either in source code or as a precompiled package. This can be daily ( nightly build ), weekly, or to any other appointments that keep developers appropriate (eg after completion of a subsystem ), done. Such a version can also be an automatic bug-tracking module included (see Amarok ) to facilitate the beta testers bug reports to the developers. This is in large projects with defined development objectives and a fixed release schedule is usually the norm ( GNOME).
• The beta version is given in the source control system to a defined revision with a tag ( a tag ), but not otherwise dealt with separately. Independent providers can then use this level of development as the basis for their precompiled packages. This comes in very rapidly changing projects that may work without any or only with rare solid releases, but where there is still a general interest in current versions, for use ( Dirac, Xine ).
• There is no fixed beta, beta is the current HEAD, ie the ever-changing, actual state of development. Beta testers need the current state even download from the source control system, configure and compile, this activity is usually done automatically by scripts provided by the project. This is the most common case, but can also be combined with one of the two previous methods (which is the control ).

Perpetual Beta

A term that describes that evolve continuously with respect to the constant development of the Internet websites and software and thus are never really finished. Thus a perpetual state of development has occurred, the " Perpetual Beta". Established as a keyword within the Web 2.0 concept, which takes into account the Extreme Programming concept of " Continuous Integration ".

Release Candidate / Prerelease

A Release Candidate ( RC short, v. Engl. Due for release candidate), sometimes called a pre-release ( v. Engl. Around for pre-release ), is a final test version of software. It includes all the features that you want the final version of the software included, already available (so-called feature complete ), all previously known errors are corrected. From the Release Candidate, the final version is created to perform a final product and system testing before release. The quality of the software is checked and searched for any remaining bugs.

If even one little thing changed, another Release Candidate must be created, and the tests are repeated. The release candidates are therefore often numbered (RC1, RC2, etc.). No further changes and keeps a Release Candidate finally the required quality standards, so the suffix RCx is removed and thus the version declared Release and published.

Versions that are significantly more stable than beta versions, but do not yet have the status of a Test Release Candidate are referred to in some development projects as gamma version.

For device drivers for Windows, there is sometimes the status WHQL Candidate. This is a RC corresponding driver version that the manufacturer has submitted to WHQL testing, the appropriate certification is not yet done.

Release

The completed and published version of a software is called release. This causes a change in the version number, usually a high counting the version number associated. In a media- bound distribution of this version is delivered to the production to the pressing plant where they copied to media such as CD- ROMs or DVDs, is thus produced as actual tangible product.

For this state is also different names have been established:

Troubleshooting after publication

To correct errors in previously published software, provide software manufacturer so-called updates, hotfixes, patches and service packs out. In many modern applications, and operating systems, this can be obtained via the Internet manually or automatically.

Firefox as an example

The web browser Mozilla Firefox is produced in six -week intervals in three different versions: the experimental version Firefox Aurora, the largely stable version Firefox beta and the stable version Firefox, each differing in their version number, eg Firefox Aurora 11, Firefox Beta 10 Firefox 9 In addition, you can the " nocturnal " nightly build (current level of development, only suitable for testing ) to download. In this way, on the one hand to accelerate the development process, on the other hand, users can use the versions Beta or Aurora help test future functions of the stable version to assess and identify bugs and security vulnerabilities at an early stage, as the Aurora version twelve and the Beta version will be made ​​available six weeks before the final release of the stable version of the public.