software engineering – How do you decide if an application is in alpha, beta, RC or RTM?

Question:

Each Windows has alpha, beta, RC and RTM versions, and as you move from left to right in these versions it will get 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's 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?

Answer:

Origin

These nomenclatures started to be used after IBM classified their hardware as A, B or C according to what stage the product was 1 . Then the software started to have similar terminology but using Greek letters instead. Other vendors liked the idea and started adopting these and new nomenclatures for product development/launch phases.

Marketing

Everyone decides what is best for them. I never saw a clear rule of when each should be used. It is true that hardly a specific organization is clearly better than the other, even because it is more of a nomenclature, an instrument for communicating releases. 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 project organization, with 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 reaching a certain level of maturity and/or establishing that certain tasks or updates will no longer be accepted.

These nomenclatures are rarely used in smaller projects, especially internal to a company.

I'm going to build on the Wikipedia software release article.

pre-alpha

Refers to all activities performed during the software project prior to testing. Such activities can 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 feature is implemented. In closed source it is not common for the public to have access to these versions.

Alpha

First phase where testing starts — alpha is the first letter of the Greek alphabet, also used as the number 1. In this phase, developers often perform white-box testing. Additional validations are done with black-box testing by a specific testing team.

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

It is already common to see alpha releases, sometimes called milestone or CTP (*Community Technology Preview). These releases tend to be more reliable and run away from the original idea of ​​alpha releases but they aren't usually exactly a beta either as the project is still in a state that allows for many fundamental changes.

Beta

Beta, the second letter of the Greek alphabet and representing the number 2, names the phase after alpha. It usually starts when there is no more destructive functionality to be implemented in the software. The focus in the beta version is to reduce impacts to users, often incorporating usability tests. The process of releasing a beta version is called a beta release and is typically its first public release, outside the confines of the developing organization.

Beta users are called beta testers ("beta testers"). Generally, this group is made up of prospective consumers who accept to participate in the tests without being paid for it, although they often earn discounts or some type 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 split the beta into:

  • closed – restricted to a group of users chosen by the developer;
  • open – released to anyone who wants to participate in the test.

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

release candidate

The term release candidate , or simply RC, refers to a release with the potential to be the final product, ready to be released unless a serious bug appears. At this stage of product stabilization, all features are specified, implemented and tested through one or more beta phases without the occurrence of serious bugs .

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

The term "golden master" is also used to designate this stage, and the last 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 testing phase, with omega or zenith for final test versions and considered to be bug- free, ready for production.

A release is named code complete when the development team agrees that the release will not include any additional source code, although there may still be code changes to fix defects. There may also be a change in documentation or data files, or in the code used for testing.

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

RTM

The terms release to manufacturing or release to marketing , both abbreviated as RTM, are used when the software is ready for the end consumer. The initials RTM are typically used in certain contexts where there is production for a large audience, as opposed to software for a more restricted audience — such as special purpose or government software — notably those distributed with hardware components or sold in large chain stores.

GA

The term general availability is the point where all necessary marketing activities have been completed and the software has been made available to the market, either via the internet or in physical media.

Commercial activities may include geographic availability of the product, translation into multiple languages ​​according to target markets, and completion of security testing. The time between RTM and GA can range from weeks to months, depending on the commercial demand required by GA.

This is the stage when the product is considered "alive" — it's the final version. Such a version is said to be very stable and relatively bug free, with an acceptable quality for all end users. In games, this version is also known as gold .

It may also be known as RTW ( Release to web ). It is more and more common for general releases to be made openly on the web.

Some releases may be classified as long term support , or LTS, which gives them the assurance that they are upgradable to the next LTS and enjoy manufacturer support for a longer time than non-LTS releases .

EOL

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

Scroll to Top