CAMARA Release Process - Coverage of Fall25 Release PR checks

C1 – Continuous Validation on main

Full linting and schema checks (YAML + OpenAPI), enforcing the work‑in‑progress rule. CI ensures main always contains placeholders and never concrete release values.

Placeholders only: info.version: "wip", {{version}}, {{api_version}}; placeholder server URLs.

C2 – Automated Release Branch Generation

On release trigger, tooling creates the release branch, replaces placeholders with computed values (exact versions, server URLs), and writes release-metadata.yaml.

Concrete values set only in release branch.

C3 – Release Preparation & Review

Manual review through PRs to release branch; branch protection enforces CODEOWNERS and reviewers approvals.

—

C4 – Tagging & Post-Release Sync

Create tag, publish artifacts (including release-metadata.yaml), and open a sync PR to main. main stays with placeholders.

—

C5 – Maintenance / Patch Release

Apply the same C2–C4 flow on maintenance-rX branches for hot‑fix releases (release_readiness: patch-release).

—

YAML and OpenAPI schema validity

CI runs MegaLinter + schema checks on every PR to main.

C1

Version field handling (info.version)

Must be "wip" on main; real value is computed from target_version with auto‑incremented suffix (e.g., -rc.2) in the release branch.

C1 → C2

Server URL pattern enforcement (“Version in URL path”)

Placeholder format validated on main; concrete vX.Y replaced during release generation.

C1 + C2

API status / repository readiness coherence

CI cross-checks release_readiness vs each api_status.

C1

Existence of API definitions and tests

Required for all alpha or higher APIs; CI fails if missing.

C1

No changes to unchanged APIs

CI diff against previous release tag; reference point on main marked by src/X.Y.

C1

Dependency references (Commonalities / ICM)

Only meta-release references on main; concrete tag refs inserted in release branch.

C1 + C2

Placeholder replacement

Done automatically for {{api_version}}, {{commonalities_version}}, etc. in release branch.

C2

Generation of release-metadata.yaml

Scripted from release-plan.yaml + commit SHA.

C2

CHANGELOG generation

Auto-generated (as far as possible), edited and reviewed via release prep PR.

C2 + C3

Readiness checklist validation

Evaluated from metadata; results shown in release PR.

C2 + C3

Approval and branch protection

Required CODEOWNER approval before tag.

C3

Tag creation and artifact publishing

After approval CI creates rX.Y tag + GitHub Release w/ artifacts.

C4

Post-release PR to main

After tagging, automation opens a PR to main that adds the new CHANGELOG.md and README entries (e.g., updated API tables). All version fields on main remain as "wip", and for public releases the release-plan.yaml is updated to set all APIs to unchanged, enforcing explicit planning for the next cycle.

C4

src/X.Y tag creation

Marks branch point on main for maintenance.

C4

Maintenance / patch releases

Executed on maintenance-rX branches with same checks as main releases.

C5

C1 – Validation on main

Ensure structure, “wip” state, and metadata correctness.

All PRs to main.

CI reports, schema lint logs.

C2 – Release Branch Generation

Replace placeholders, compute versions, generate metadata + CHANGELOG.

On release trigger (e.g. issue with label).

release-metadata.yaml, CHANGELOG.

C3 – Review & Approval

Manual review of release branch artifacts.

PRs to release/rX.Y.

Reviewed PRs, branch protections ensure needed approvals.

C4 – Tag & Sync Back

Tag, publish, open sync PR to main (CHANGELOG, README, update release-plan.yaml to unchanged where applicable).

After approval / tag.

GitHub Release, src/X.Ytag, sync PR into main.

C5 – Maintenance

Patch releases on older cycles.

When needed.

maintenance-rX branches, patch tags.