Image Description
Alpha, beta and release candidate versions
Alpha. Beta. RC.
If you've downloaded software for any length of time, you've probably met at least one of them. They sound important, but what are they actually telling you?
They are labels developers commonly use for pre-release software: versions made available before the developer considers a release finished and stable.
There is no worldwide alpha police force, so projects do use the terms differently. Treat the project's own documentation as the final word. Still, the following meanings are very common.
Alpha
An alpha is usually an early testing version. The basic idea may work, but features can be incomplete, things may change significantly and bugs are expected.
If you release an alpha, be clear about that. Someone installing it should not have to discover the experimental bit when it eats their settings.
Beta
A beta is generally further along. Most of the intended features are often present and the focus may be moving towards testing, fixing bugs and finding the odd problem that only appears when somebody uses the program in a way you never imagined.
Beta does not mean bug-free. If it did, software developers everywhere would be delighted and rather suspicious.
Public betas can be useful because more people, computers, screen readers, configurations and usage styles get involved in testing.
Release candidate, or RC
A release candidate is a version the developer believes could become the final release if no serious problems are found.
You might see 2.0.0-rc.1, followed by 2.0.0-rc.2 if something needs fixing. If the candidate survives testing, the project can then release 2.0.0.
A typical journey
2.0.0-alpha.1 2.0.0-alpha.2 2.0.0-beta.1 2.0.0-beta.2 2.0.0-rc.1 2.0.0
That is an example, not a compulsory ritual. You do not have to release two alphas, two betas and an RC because a tutorial on the internet showed you a nice list.
Do I need all three?
No. A small personal utility might go straight from development to a normal release. Another project might use betas but never call anything alpha. A large project may have nightly, preview, beta and release candidate channels.
Use labels when they communicate something useful to your users.
What should testers expect?
Tell them. "Beta" alone does not explain whether settings may be reset, whether file formats can change or whether the software should be trusted with important data.
A short note saying what is stable, what is unfinished and how to report problems is far more useful than expecting everybody to share your private definition of beta.
What should I call my first public test?
If the software is very early and you expect major changes, alpha is a reasonable description. If the main features are there and you primarily want broader testing, beta may fit better. If you think the exact build could become the final release, you are getting into release candidate territory.
Don't spend three days arguing with yourself over the label, though. The description you give testers matters more than the impressive Greek letter.
How does this fit into version numbers?
Some versioning systems have formal rules for pre-release labels. Semantic Versioning, for example, supports identifiers after a hyphen, giving versions such as 1.0.0-beta.1. That's what we'll look at next.
Further reading and external resources
Previous: Understanding software versions | Next: Introduction to Semantic Versioning