Alpha, beta, RC, GA: what release stages actually promise

Someone evaluating your software asks one question: “can I run this, and what happens to me if I do?” The industry answers with a zoo of words — alpha, beta, release candidate, GA, canary, nightly, preview, early access, experimental — and most of them are used loosely enough that they answer nothing. That looseness isn’t free. These words carry decades of inherited meaning, and people make real decisions based on them: an operator schedules a production rollout because you said “stable,” a developer builds on an API because you said “GA,” a tester tolerates a crash because you said “alpha.” Use a stage name against its inherited meaning and you don’t just confuse people — you spend trust you’ll want later.

This guide pins down what each stage actually promises, how the words map onto version numbers and release channels, what the modern euphemisms (“preview,” “early access”) are doing, and — because this is a changelog site — how to announce the transitions, which are some of the most-read entries a product ever publishes.

A stage name answers three questions

Strip away the Greek letters and every stage label is a compact answer to three questions:

  • How finished is it? Are features still being added or removed? Will interfaces — UI, API, file formats — change under you?
  • What’s allowed to break? Crashes? Data loss? Silent wrong answers? Or nothing at all?
  • What do you owe the people running it? Bug fixes? Security patches? A migration path? A support channel? Nothing?

The stages below are the industry’s standard answers, in order. The exact boundaries vary by team — that’s fine, and the fix for the variance comes later in this guide: publish your definitions. What’s not fine is using a word whose standard answer contradicts yours.

The ladder, rung by rung

  • Nightly / canary: the promise is freshness, nothing else. A nightly is built automatically from whatever the main branch looked like at build time; a canary build additionally goes to a small first slice of real users or traffic — named for the coal-mine bird, because its job is to die first. Neither makes any claim of working. There are no release notes in the crafted sense; the commit log is the documentation, and that’s appropriate — the audience chose maximum freshness over any stability promise. If a canary build misbehaves, the correct communication is a rollback, not an apology post.
  • Alpha: incomplete by design. Features are missing, interfaces will change without notice, and data created in an alpha may not survive to the next build. The promise is direction, not stability: “this is what we’re building — tell us if it’s the wrong thing.” Alpha feedback is about whether, beta feedback is about whether it works. Alphas are opt-in by definition; an “alpha” that users receive by default isn’t an alpha, it’s a stable release you’ve pre-excused.
  • Beta: feature-complete, bug-expected. The shape is settled; what’s being tested is whether it survives contact with real usage. Interfaces should be mostly frozen — late breaking changes in beta deserve loud entries, because beta users have started building habits and integrations on the current shape. The implicit contract: users tolerate bugs, you triage their reports fast and say what you fixed. Writing for these readers is its own craft — see beta and early-access release notes — but the short version is that beta readers are your best readers, and a known-issues list is the cheapest trust you can buy them.
  • Release candidate: the promise is a freeze. An RC says “we believe this exact build is the release — prove us wrong.” The only changes allowed between RC and final are fixes for showstoppers found in the RC; rc.2 exists because rc.1 failed. An RC that gains a feature is not a release candidate — it’s a beta wearing a costume, and everyone testing it can tell. RC notes are short by nature: what changed since the last RC, and what would stop the release.
  • GA / stable: the compatibility promise starts now. General availability means anyone can get it, you support it, the documented interfaces are the real interfaces, and breaking changes from here on are governed by your versioning scheme and deprecation policy. This is the rung where semver’s promise attaches — before GA, version numbers describe; after GA, they commit. It’s also the only rung whose announcement is genuinely launch-grade news.
  • Maintenance / LTS: supported, no longer growing. Fixes and security patches continue; features land in the next line. The audience is people who chose boredom on purpose, and their release notes answer exactly one question: is this update safe and necessary?
  • End of life: the last promise is a date. No more fixes, including security fixes — which makes continuing to run it a risk decision someone else is making with your silence. Announce it like the sunset it is: date, migration path, reminders, and a final entry that closes the line’s history.

How version numbers encode the ladder

Semver has a slot for all of this: pre-release identifiers. 2.0.0-alpha.1, 2.0.0-beta.3, 2.0.0-rc.1 all precede 2.0.0, and they sort in exactly that order — alphabetically, which is the quiet reason the industry settled on Greek-letter names that alphabetize correctly. The hyphen is machine-readable opt-in: package managers won’t give a pre-release to anyone who didn’t explicitly ask, which makes it the one place the whole ladder is enforced by tooling instead of etiquette.

Two traps. First, the eternal 0.x: semver says anything may change before 1.0.0, and some projects camp there for a decade while thousands of production systems depend on them — a stage label (“pre-release”) contradicted by reality (load-bearing infrastructure). If people build on it, version it like they do. Second, the inverse: products that version by date or ship continuously still pass through these stages — they just have to say so in words, because the version string no longer carries the information. A SaaS feature’s “beta” badge in the UI is doing the job semver’s hyphen does for libraries.

Channels are not stages

Browsers made the vocabulary confusing: Chrome and Firefox ship channels — stable, beta, dev/aurora, canary/nightly — and the words look identical to stage names. The difference: a stage is a phase one release passes through on its way to done; a channel is a persistent track a user subscribes to. A release graduates out of beta; a beta-channel user is in beta forever, receiving each release a few weeks early, by standing choice.

The communication consequence: channels need per-channel streams, not one interleaved feed. Your beta-channel subscribers want beta-cadence notes; your stable-channel users should never see them, or the churn teaches them your changelog is noise. Run the streams separately — separate feeds, separate pages — and post the graduation summary to the stable stream when a release crosses over. The two-streams pattern is the same one beta programs use, generalized.

Preview, early access, experimental: the modern blur

Three newer labels do real work, and each hides a specific ambiguity:

  • “Preview” is enterprise-speak for alpha-or-beta, popularized by cloud vendors whose lawyers needed a word that pairs with an exclusion: preview features typically carry no SLA and can change or vanish. The word itself doesn’t say which of those applies — the vendor’s published preview policy does. If you adopt the word, adopt the policy too.
  • “Early access” is gaming’s version of a paid open beta — and its lesson generalizes: because money changed hands, the audience expectations are higher than the stage label implies, and steady, honest patch notes are the product during the early-access years. If you charge for pre-stable software, communication cadence is part of what was purchased.
  • “Experimental” is a per-feature stage inside a stable product — usually behind a feature flag. It’s honest and useful precisely because it’s scoped: the product is GA, this toggle is not. The failure mode is scope creep, where “experimental” features accumulate production users and the label quietly becomes a liability shield.

The pattern behind all three, and the fix for stage-name looseness in general: publish your definitions. A short stability policy — what each label promises about change, support, and data — turns fuzzy vocabulary into a contract, and it takes twenty minutes to write:

STABILITY POLICY (template — edit the promises, keep the structure)

  Experimental — may change or disappear without notice.
    No support commitment. Data created here may not migrate.
    Feedback: #experimental channel.

  Beta — feature-complete; interfaces frozen except for
    showstoppers. Bugs expected and triaged within <N days>.
    Data is durable and will migrate to GA.

  GA — supported. Breaking changes only per our
    deprecation policy (<link>), announced <N months> ahead.

  Labels appear on the feature’s docs page and in the
  changelog entry that introduces it.

Announcing the transitions

Stage transitions are changelog entries — often better-read than the features themselves, because a transition is exactly the information an evaluator was waiting for. The rules:

  • Graduation is the news. “Exports is now GA” is a launch-grade entry: what stabilized, what the compatibility promise now covers, what changed since beta, and thanks to the beta users who got it there. Write it like the feature announcement it is.
  • Demotion and removal are louder news. An experiment that didn’t make it deserves an honest entry with an off date and a migration note, not a silent disappearance — silence is how “experimental” labels lose their permission to exist.
  • The entry states the stage. Every entry that introduces a pre-stable feature carries the label and a one-line pointer to the stability policy. Readers skimming the feed shouldn’t need to already know your program structure.
  • Pre-stable churn stays in its stream. Day-to-day alpha/beta/RC iteration belongs to the pre-release feed; the stable stream gets the graduation summary. One pipeline, two audiences.

Six anti-patterns

  • The eternal beta. Years of production use, revenue, and paying customers under a “beta” badge kept as a liability shield. The label stopped being information and became an excuse — and users can tell, which means it no longer even works as an excuse.
  • The growing RC. rc.3 has two new features. Nothing you call a release candidate is one if features are still landing; the freeze is the promise.
  • Default-on alpha. Pre-stable software delivered to people who didn’t opt in. The stage label describes what users chose; remove the choice and the label is just a pre-written apology.
  • GA by silence. The product left beta in everyone’s minds except the docs, or the library is load-bearing at 0.9.47 — nobody ever said it was stable, so every adopter is guessing. Stability is a statement; make it, dated, in the changelog.
  • Stage soup. Marketing says GA, the docs say preview, the API returns a beta header, the pricing page sells it. Whatever the truth is, the contradiction reads as either disorganization or evasion — and an evaluator assumes the worst of the three answers.
  • Renaming mid-flight. The same build is “beta” in March, “preview” in May, “early access” at launch. Each rename resets what the label means and burns the vocabulary’s value. Pick words once, define them, and let the software move through them instead.

Where Wakelog fits

Stage communication is mostly discipline, but the plumbing helps. Separate projects per channel give your beta and stable streams their own pages, feeds, and widgets, so pre-release churn never trains stable users to unsubscribe — or run the beta stream unlisted while the program is invite-only. Tags mark stage in-stream, drafts + publish_at let you write the graduation entry during the RC freeze and have it go live the moment GA does, and stable permalinks mean “when did this go GA?” has a linkable, dated answer forever — which is exactly what enterprise evaluators and questionnaires ask.

Honest caveat: Wakelog doesn’t manage release trains, build channels, or enforce your freeze — no tool makes an RC stop growing. The stages are promises only you can keep. What Wakelog gives you is the public, dated record of making and keeping them — which, for a word like “stable,” is the whole game.

Put your stage promises on the record   Next: beta and early-access release notes →

Related guides

Last updated 2026-08-01 · All guides