How do you decide whether an application is in alpha, beta, RC or RTM?

Asked

Viewed 1,448 times

22

Each Windows has alpha, beta, RC and RTM versions, and as you advance from left to right in these versions it gets more "ready". As for RC and RTM, I don’t know if this is used in other software, but in general it is used to talk about alpha and beta versions. I also know that you don’t jump directly from one to the other. It is not because it starts in alpha that the next version is beta, so much so that there are alpha 1, alpha 2, etc.

Anyway, I keep asking myself, how do you make decisions about this? How do you know if a software is in alpha, beta, RC or RTM? What are the criteria used to determine this?

1 answer

19


Origin

These nomenclatures began to be used after IBM classified its hardware as A, B or C according to the stage the product was at1. Later software began to have similar terminology but using Greek letters instead. Other suppliers liked the idea and started to adopt these and new classifications for product development/release phases.

Marketing

Everyone decides what is best for them. I’ve never seen a clear rule of when each should be used. It is true that one organization is hardly clearly better than the other, because it is more of a nomenclature, a tool for communicating launches. The most important thing is to be consistent in the project. Your users need to know what each name means to your project. This has little to do with the organization of the project, with the versioning itself. It is much less an engineering technique and more a marketing technique.

How to choose a strategy

You can set goals and objectives for each phase. In some cases what defines the transition from one phase to another is an established date. But the most common is to reach a certain level of maturity and/or the establishment that certain tasks or updates will no longer be accepted.

These classifications are rarely used in smaller projects, mainly internal to a company.

I’m gonna go with the article software release wikipedia.

Pre-alpha

Refers to all activities carried out during the software project prior to testing. Such activities may include requirements analysis, software design, development and unit testing.

In a typical open source development, there are several pre-alpha versions. Versions called Milestone include specific sets of functions, and are released as soon as the functionality is implemented. It is not common for the public to have access to these versions.

Alpha

First phase where testing begins - alpha is the first letter of the Greek alphabet, also used as the number 1. At this stage, developers usually perform white box testing. Additional validations are made with black box tests by a specific testing team.

Alpha software can be unstable and cause crashes or data loss. The exception is when alpha is publicly available, where developers focus more on stability, so that testing can be done more extensively. In closed projects the publishing of software in alpha version, however, is not common. Although this is changing. Or the whole concept is changing.

It’s common enough to see alpha launches, sometimes called Milestone or CTP (*Community Technology Preview). These releases are usually more reliable and run away from the original idea of the alpha releases but are also not exactly a beta since the project is still in a state that allows many fundamental changes.

Beta

Beta, the second letter of the Greek alphabet and representative of the number 2, gives name to the later phase of alpha. It usually starts when there are no more destructive features to be implemented in the software. The focus of the beta version is to reduce impacts to users, usually by incorporating usability tests. The release process of a beta release is called beta release and is typically its first public disclosure, outside the boundaries of the developing organization.

Users of beta versions are called beta testers ("beta testers"). This group usually consists of prospective consumers who agree to participate in the tests without being paid for it, although they often get discounts or some kind of compensation, or even receive the software for free.

Beta versions are widely used as demonstrations within the organization and for external customers. Some developers refer to this version as preview, Technical preview or Early access ("Early access"). In some cases these versions are released in a state closer to alpha.

Some software is kept in perpetual beta. This gives developers more freedom to work and avoids certain compromises.

In closed-source projects it is common to divide the beta into:

  • closed - restricted to a group of users chosen by the developer;
  • open - released to all who wish to participate in the test.

In lesser known projects it is common to have only this phase (or neither) named before the official release.

Release candidate

The term release candidate ("release candidate"), or simply RC, refers to a version with the potential to be the final product, ready to be released unless any bug seriously show up. At this stage of product stabilization, all functionalities are specified, implemented and tested through one or more beta phases without the occurrence of bugs serious.

Lately I have seen the use of the term even in cases that were normally considered beta.

The term "golden master" is also used to designate this phase, and the latter golden master is used as the final version. Other letters of the Greek alphabet, such as gamma and delta, are used to indicate substantially complete versions, but still in the testing phase, with omega or zenith for final test versions and taken as free from bugs, production-ready.

A release is named complete code ("complete code") when the development team agrees that the version will not include any additional source code, although there may still be code changes to correct defects. There may still be changes to documentation or data files, or to the code used for testing.

In some cases end up working as an early product demo.

RTM

The terms release to manufacturing ("launching for manufacture") or release to marketing ("market launch"), both abbreviated as RTM, are used when the software is ready for the final consumer. The initials RTM are typically used in certain contexts where there is production for a large audience, as opposed to more restricted public software - such as software for specific or governmental purposes -, notably those distributed with hardware components or sold in large store networks.

GA

The term general Availability ("general availability") is the point where all the necessary marketing activities have been completed and the software has been made available to the market, whether on the Internet or on physical media.

Commercial activities may include the geographical availability of the product, translation into several languages according to the target markets, and completion of safety tests. The time between RTM and GA can range from weeks to months, depending on the commercial demand required by GA.

This is the stage where the product is considered "live" - is the final version. Such version is considered as very stable and relatively free from bugs, with an acceptable quality for all end users. In games, this version is also known as gold ("gold").

Also known as RTW (Release to web). It is increasingly common for general releases to be made openly on the web.

Some versions can be classified as long term support (""), or LTS, which gives them the assurance of being upgradeable to the next LTS and enjoying manufacturer support for a longer time than non-LTS versions.

EOL

End of life ("end of life") or end of line ("line end") is another milestone also used to indicate when a version will no longer be supported or at least will not have the support guaranteeing in the same way.

Browser other questions tagged

You are not signed in. Login or sign up in order to post.