Release Candidate

Software isn’t created all at once. A program is written, changed, and tested repeatedly over months. Shortly before the official release, there is a special intermediate stage: the release candidate. This is a version that, from the developers' point of view, is finished. All planned features are built in, all known serious bugs are fixed. Nevertheless, it is first released only for testing. Only if no major problem shows up during this test phase does this exact state become the final version.

The last brake before release

The later a bug is discovered, the more it costs. As long as a program is only tested in-house, a fix is cheap. But if the version is already installed on millions of devices, it becomes expensive and embarrassing. The release candidate is the last chance to prevent that.

The reason for this phase is simple: developers cannot recreate every situation. Users have different devices, different settings, different habits. A program that runs cleanly in the test lab can crash on an old laptop with an unusual graphics card. Such cases are only found when many different people actually use the software.

The rule behind this is important: no new features are added to a release candidate anymore. This is called a feature freeze, meaning the scope of functionality is frozen. Only fixes for real bugs are still allowed. This self-restraint ensures that every change makes the program more stable rather than introducing new risks.

From alpha through beta to the release candidate

Before the release candidate, there are usually two other stages. The alpha version is an early state, often incomplete and unstable. It usually stays within the company. The beta version already goes out to outsiders, but still contains known gaps and bugs. Only after that comes the release candidate as the most mature preliminary stage.

Such versions can be recognized by their number. A label like 5.0-rc1 means: first release candidate for version 5.0. If someone finds a serious problem, the developers fix it and release 5.0-rc2. This cycle can repeat several times. The Linux kernel, the core of many servers and Android phones, goes through around seven such rounds before each release.

If a round stays quiet, something unspectacular happens: the last candidate is renamed to the final version without any further changes. The program code is therefore identical, only the label changes. That is exactly the point of the exercise. The released version is meant to be exactly the state that many people have already tested.

Where you run into the term

Release candidates are most commonly encountered in software whose development takes place publicly. The Firefox browser, the Ubuntu operating system, or the Python programming language openly announce their candidates. Anyone who wants to can download them and help test. Such phases also exist for video games, usually under the name beta or playtest.

In the world of AI, the term is heard less often, but the principle is widespread. New language models often first appear as a preview or as a version labeled experimental. There, too, the goal is to gather feedback from real-world use before a provider recommends the model for reliable ongoing operation.

A common misconception is that a release candidate is practically already the finished version and therefore safe to use without concern. That is not true. It is a proposal, not a promise. Such software has little business being on the computer you’ll use the next day to prepare for an exam. Anyone testing it should expect that something might go wrong.