Code Freeze and Release Candidate Workflow

A code freeze is not “stop all coding.” It means restricting what can enter the release line. An RC is not final release; it is a testable candidate snapshot.

Inputs

release scopequality gatesrollback policy

→cut release branch → tag rc → accept only fixes

Outputs

auditable candidate versionsclear defect-convergence pathsafer production release

The core objective is scope convergence, not endless patch accumulation.

What this workflow solves

Without freeze boundaries, teams often face:

• moving release scope during final validation
• unclear defect attribution because baseline keeps changing
• repeated date slips with poor visibility

Freeze + RC creates a stable target surface for release verification.

Recommended sequence

1. Cut release branch from current main

git fetch origin
git switch main
git pull --ff-only origin main
git switch -c release/2026-04

2. Tag the first RC

git tag -a v2026.04.0-rc1 -m "Release candidate 1"
git push origin release/2026-04 --tags

3. Freeze admitted change types

Typical freeze-window admissions:

• blocker bug fixes
• mandatory release configuration fixes
• urgent security or compliance items

Everything else waits for the next iteration.

4. Produce new RC tags after each fix round

git switch release/2026-04
# merge or cherry-pick approved fixes
git tag -a v2026.04.0-rc2 -m "Release candidate 2"
git push origin release/2026-04 --tags

5. Publish final release tag after gates pass

git tag -a v2026.04.0 -m "Release 2026.04.0"
git push origin v2026.04.0

Two common ways to move fixes into RC

1. commit directly on release branch (small urgent fix)
2. fix on dedicated hotfix branch, then cherry-pick into release

Either is fine when every admitted fix remains traceable and intentional.

!Freeze windows fail when teams sneak in non-essential changes

“Since we are here, let’s include this small improvement too” is a classic release destabilizer. Freeze periods prioritize predictability over opportunistic scope growth.

Common mistakes

Mistake 1: interpreting freeze as zero engineering activity

Freeze limits release-line intake, not all ongoing development.

Mistake 2: overwriting old RC tags

Create new RC tags per iteration to preserve verification history.

Mistake 3: fixing only on release line and never backporting to main

That creates long-term divergence between release and trunk.

→Prepare a freeze checklist for your next release

1. Define admitted change categories during freeze.
2. Define pass gates for each RC round.
3. Standardize RC tag naming.
4. Assign ownership for backporting release fixes to main.

Good follow-up reads

1. Release branch workflow
2. Hotfix and urgent fixes
3. Post-release multi-branch backporting