Draft File Modifications: Adopt a Dual-Phase Meta-Release Cadence for CAMARA API

Github

CAMARA-API-Desing-Guide.md (link)​

• The guide does not mention Spring or Fall explicitly, but in Block 7 (Versioning) it defines API states: sandbox and stable.​

• Until now, these states were handled without a direct link to the release calendar.​

• With the dual-phase cadence, the distinction is no longer purely semantic:​

  • Sandbox APIs can be published at any time.​

  • Stable APIs are tied to the meta-release cycle – not two rigid windows, but with a pattern:​

    • Most stable APIs are released once a year (Fall).​

    • Commonalities/ICM changes are concentrated in Spring.​

• Example: if new commonalities are released in Spring26, the next iteration will be Spring27, while stable APIs will adopt them in Fall26.

Wiki

No changes needed.

Github

There is no need to modify these documents with cadence or version details, since the dual-phase proposal does not affect authentication or consent flows. Security/consent flows remain consistent in both scenarios (sandbox and stable).

Wiki

No changes needed.

Github

API_Release_Guidelines.md (link)​

This document must be updated to introduce the dual-phase cadence, since it is one of the most affected. It currently defines: What a meta-release is (today Spring/Fall, always twice per year), the requirements for initial (0.x) and stable (≥1.x) APIs, and how APIs align with Commonalities and ICM All mentions of meta-release need to be rewritten to reflect that it is no longer two symmetric cycles, but a dual-phase scheme.​

Concrete actions:​

• Update the definition of meta-release.​

• Review the section on public API versions. Today it separates initial and stable, but without calendar connection. The dual-phase logic must be introduced:​

  • Initial (0.x): continuous publication, optional in meta-release.​

  • Stable (≥1.x): mainly released in Fall, with backward compatibility.​

• Update process sections (M3/M4). Today it assumes all APIs reach these points in each half-yearly cycle, but under dual-phase only stable APIs must comply with M3/M4 in the stable window (Fall), while sandbox APIs follow a more flexible flow with continuous validations.​

• Review alignment with Commonalities/ICM according to the dual-phase.​

• Include release process examples adapted to the new dual-phase model

Wiki

Meta-release Process (link)​

This wiki currently defines meta-releases as two per year (Spring and Fall), at 6-month intervals. It explains that all APIs (initial and stable) must follow milestones M0–M6 in each meta-release, using the same calendar for Spring and Fall with full symmetry.​

This needs to be rewritten to reflect that there are no longer two symmetric meta-releases, but a dual-phase model: Spring = Commonalities/ICM + Fall = Stable APIs​

Concrete actions:​

• Update the definition of meta-release.​

• Rewrite the calendar: keep the two slots (Spring/Fall) but with different content.​

• Update rules for API trackers, clarifying that sandbox APIs may remain outside the process, while stable APIs must comply with Fall meta-release milestones.​

• Adjust skipping criteria accordingly.

Review guidance for API release PRs (link)​

Currently, only minor wording adjustments are needed plus an explicit note on sandbox vs stable to align with the dual-phase model. At present, the document states that PR reviews are done for approval at M3 (release candidate) and M4 (public release). It also explicitly mentions that for APIs aiming to become stable, release management may request an additional review of Commonalities and ICM.​

Concrete actions:​

• Sandbox vs. Stable distinction: The current assumption is that any API will go through M3/M4 in every meta-release. Under dual-phase, it must be clarified that sandbox APIs can be released at any time, so PR reviews do not need to be tied to M3/M4 milestones, while stable APIs must go through review at the Fall milestones.​

• Commonalities/ICM reviews: Today the example is Spring 25. This wording should be updated to be timeless and aligned with the dual-phase model.​

• Checklists and templates: Add a note stating that sandbox PR reviews may occur outside the meta-release cycle, while stable APIs must comply with the Commonalities/ICM from the latest Spring and undergo formal review in Fall.​

API versioning (link)​

The document defines version types, the flow, and how they are used. It does not mention Spring/Fall, but it assumes that all public API versions are proposed for meta-release. The document does not require major redesign, but it does need three key wording changes.​

Recommended actions:​

• Review the definition of public API version.​

• Update the version creation flow: limit the requirement of milestones to stable versions only.​

• Precedence examples: add an example of a sandbox release outside a meta-release.​

FAQ & Feedback (link)​

Only wording changes are required in the FAQs to break the Spring/Fall symmetry and reflect that now only Fall is the meta-release for stable APIs, while Spring covers Commonalities/ICM.​

Recommended actions:​

• Review all FAQs mentioning Spring/Fall and update them to the dual-phase logic.​

• Adjust stability prerequisites so they refer only to Fall as the reference for breaking changes.​

• Rewrite the FAQ on release trackers to reflect sandbox vs. stable vs. Commonalities.​

• Neutralize date-based examples.

Release Management Working Group description (link)​

The current text defines the old model of two symmetric meta-releases. With the dual-phase model, this symmetry must be broken, clarifying that Spring → Commonalities/ICM and Fall → Stable APIs.​

Recommended actions:​

• Rewrite the definition of meta-release.​

• Update the section on API releases:​

  • Incubating/Graduated APIs → released in Fall​

  • Sandbox APIs → out-of-cycle​

• Remove any wording that implies symmetry.

Github

ProjectStructureAndRoles.md (link)​

The document defines repository maturity stages (Sandbox → Incubating → Graduated). The required changes are mostly clarifications: making it explicit that Sandbox = continuous and Stable = aligned with Fall.​

Concrete actions:​

• Sandbox → Stable under dual-phase: clarify that repositories in sandbox may release versions at any time, and only once they reach stability do they enter the meta-release cadence → normally in Fall.​

• Review mention of “same release milestones”: today it assumes all subprojects are synchronized on a half-yearly basis. Under dual-phase, stable APIs must align their milestones with the stable meta-release, while sandbox APIs are not required to and may release out of cycle.​

• Update mention of meta-release: include that under dual-phase, Spring = major Commonalities/ICM changes (optional for APIs), Fall = main window for stable APIs. This avoids suggesting there are still two symmetric release windows.

API-Onboarding-and-Lifecycle.md (link)​

This document requires a major revision because it uses “meta-release cycles” as if they were two symmetric windows per year. With the dual-phase cadence, the rules for sandbox and stable must be separated, and the criteria for transition, graduation, and archiving must be rewritten accordingly.​

Concrete actions:​

• Update references to meta-release cycle: explain that under dual-phase, sandbox APIs may evolve and publish at any time without waiting for a cycle, while stable APIs must align with the stable window (Fall).​

• Modify transition criteria between stages: moving from sandbox to incubating should no longer require participation in a meta-release if the API is still at 0.x. The criterion should be “publish at least one initial version used by an operator, or align in a meta-release if already at 1.x.”​

• Graduation stage: today it requires 2 meta-release cycles with a stable version. Under dual-phase, this should be clarified as “participation in at least two stable release cycles (Fall), or equivalent through validation and reported deployment.”​

• Archived stage: archiving criteria currently mention two consecutive meta-release cycles without activity. This should be adjusted to: sandbox = 12 months without activity or without an initial version; stable = two stable release cycles (Fall) without required updates.

Wiki

No changes needed.