Release Candidates and Production
Purpose
Section titled “Purpose”Release candidates provide a stable immutable artifact for external approval after internal validation.
Nexa context
Section titled “Nexa context”Nexa does not need an RC for every internal release. RCs add value when an external UAT party, penetration tester, compliance reviewer, or customer acceptance process needs a fixed candidate.
Standard
Section titled “Standard”-
MUST: Create an RC only after internal regression and required automated controls pass.
-
MUST: Use immutable semantic tags such as
v2026.08.0-rc.1. -
MUST: If an RC passes, create the final tag from the exact same commit; do not rebuild different source.
-
MUST: If a defect is found, fix it through the hardening process and issue
rc.2. -
MUST: Record final approval and release evidence.
-
SHOULD: Skip RCs for releases whose internal approval is final.
-
SHOULD: Use a release checklist linking CI, test, security, and change evidence.
Working model
Section titled “Working model”Internal validation → optional RC → external validation → final tag on the same commit → main/prod deployment. Image digests are retained in release evidence.
Evidence of compliance
Section titled “Evidence of compliance”Compliance is demonstrated through repository configuration, protected-branch settings, CI results, and review records. Teams should be able to show the evidence without reconstructing it manually.
Common failure modes
Section titled “Common failure modes”Rebuilding an RC for final, moving tags, or allowing unrelated changes after external validation invalidates the approval.
Maturity path
Section titled “Maturity path”The initial standard favors consistency and auditable automation. Exceptions and advanced controls are introduced only after the baseline is adopted across repositories.