Definition “Release candidate” What is a release candidate?
21.01.2022By Gedeon Rauch
A release candidate (RC for short) is a software build that is almost complete. Based on the last internal tests, critical errors are now to be eliminated so that nothing stands in the way of a public release.
Shortly before the final release of a software, release candidates serve to eliminate the last mistakes from the world.
Until a (successful) public release, developers have to prepare many software versions that have to withstand different tests. It is very certain that alpha versions (for internal testing) and beta versions (for semi-public external testing) will be used, in many cases a so-called release candidate will also be added.
This build, also called release candidate in German, is the last version before the actual release and is used as the last pre-release version to eliminate critical errors.
How does a release candidate differ from other trial versions?
A release candidate without critical errors can ultimately match the release version in the code, but a beta version will still contain some errors that make error-free operation almost impossible – special cases such as a perpetual beta are excluded.
The release candidate mainly tests the workflow and functionality, it should be ensured that the published software is executable without problems for all users. However, the fact that minor bugs can still be fixed by patches even after the release makes the use of a release candidate much more relaxed than was the case at the time of physical software.
However, since the software is otherwise complete apart from potential errors, a release candidate is also often issued as a preview version. So some – either selected or particularly eager – users get to the almost finished software earlier, while the developers can collect data in a last round of testing.
What’s next for the release candidate?
Often a release candidate is sufficient for companies before the final version, in other cases even minor errors have to be corrected. Accordingly, it is also not uncommon for there to be several versions of a release candidate, which are usually identified by the suffix RC1, RC2, etc.
After the release of all quality standards to be met and a guarantee of stability and running ability, these version appendages can finally be removed and the last release candidate becomes the final version. This software will then go on sale as the main version and will be made available to all users.
In contrast to alpha and beta versions, it is therefore not intended that a release candidate will go through many more versions. Instead, the path to release should be kept as short as possible.
The release candidate is the last step before the release
Using different builds, a development team can test (have) the extent to which your software meets your requirements and those of your target group during coding. Comprehensive testing processes begin with an internal build for internal company or team testing, a developer preview for other developers of connected software, a closed and often a public beta.
The extended publication of a release candidate could also be used as an open beta to present an almost completed version to a larger public. Whether it makes sense to use a release candidate for your own software also depends on the type of software.
Release Candidates in agile software development
In agile software development, release candidates are also used for individual features, which are tested from iteration to iteration in order to be integrated into the final release. Here, the release candidate often also refers to individual features of an existing software, an example of this would be the hosting system Drupal.
After a beta test phase, Drupal uses the stable, almost finished code to subject almost releasable features to a final test.
With announced feature freezes, these will be transferred to the next release version, further changes will only be submitted with the next stable release.
From Release Candidate to Final Build
Of course, the closer the public release of a software gets, the more developers want to make sure that there are no more system-critical bugs. The RC is the last major test version before the final version and can therefore reveal existing errors over a large area.
In the best case (and after a long beta test), the code of the release candidate is (almost) identical to that of the final build and the developers can prepare the release version to be marketed.