What changes are allowed in a release candidate?

Only critical, blocking fixes. An RC is under a change freeze or near-freeze because any change risks introducing a new problem and resetting your confidence in the build's readiness. You do not add features or make risky changes to an RC; you only fix things serious enough to block release, which is what lets it stabilize toward shippable.

How does a release candidate become the final release?

Through an iterative cycle: you produce an RC, put it through final testing (regression, smoke, verifying recent critical fixes), and if a blocker is found, fix only that and produce a new RC. When an RC passes final testing with no blocker, it becomes the release (sometimes called the gold master). Version-tagged reporting then monitors it from the first live player.

What Is a Release Candidate Build?

Q: What is a release candidate build?

A build that is potentially ready to ship, feature-complete and stabilized, undergoing final testing to confirm it is releasable. It is a 'candidate' for becoming the final release: if final testing finds no blocking issues, the RC ships; if a blocker is found, you fix it minimally and produce a new release candidate to test again.

Quick answer: A release candidate (RC) is a version of the game that could become the final release if final testing finds no blocking issues. It is feature-complete and stabilized, with only critical fixes allowed, the candidate you put through last checks before shipping. If it passes, it ships; if a blocker is found, you fix it and produce a new RC.

As a game approaches release, builds progress through stages of increasing stability, and a release candidate is the near-final one: a build you believe is ready to ship and are testing to confirm. The 'candidate' framing is precise, it is a candidate for becoming the release, pending final verification. Understanding the RC stage clarifies how the careful endgame of shipping works, where the goal shifts from adding and fixing to confirming and stabilizing.

What Makes a Build a Release Candidate

A release candidate is feature-complete (no more features are being added) and stabilized (the known significant bugs are fixed), to the point where you believe it is ready to release. It is offered up as the build that will ship if final testing turns up nothing serious. The defining mindset is that you are no longer developing, you are verifying: the RC is a frozen candidate undergoing final checks, not a work in progress.

A key property of the RC stage is a change freeze or near-freeze: only critical, blocking fixes are allowed into an RC, because any change risks introducing a new problem and resetting your confidence. You do not add features or make risky changes to an RC; you only fix things serious enough to block release. This discipline is what lets the RC stabilize toward shippable.

The Release Candidate Cycle

The RC process is iterative in a controlled way. You produce a release candidate and put it through final testing. If testing finds a blocking issue, you fix only that (minimally, to avoid new risk), produce a new release candidate, and test again. Each RC that survives final testing without a blocker found is closer to shippable. When an RC passes final testing clean, it becomes the release, sometimes called the gold master or the final build.

This cycle embodies a careful endgame: rather than declaring a build done and shipping blind, you treat each near-final build as a candidate to be proven, fixing only what must be fixed and re-verifying each time. It is deliberately conservative, because at this stage the cost of a shipped bug is highest and the value of any non-critical change is lowest.

Testing and Monitoring Release Candidates

Final testing of an RC focuses on confirming readiness: regression testing (does everything that worked still work?), smoke testing the fundamentals, and checking that the critical fixes since the last RC actually work and did not break anything. The bar for what blocks an RC is high, only serious, ship-stopping problems, but those must be caught, because once the RC ships, its bugs are live.

Capturing any issues found in RC testing with full context speeds the fix-and-re-candidate loop. Bugnet's crash reporting and bug capture tag issues with the build version, so problems found in a specific RC are tied to that build, and after you produce the next RC, version-tagged reporting lets you confirm the blocker actually stopped occurring on the new candidate. And the moment the RC ships and becomes the release, that same version-aware reporting is ready to catch anything that slipped through final testing, so the transition from release candidate to live release is monitored from the first player.

A release candidate is a build that could ship if final testing finds nothing serious. At this stage you stop developing and start confirming, only critical fixes allowed.