Proposal to Adopt a Dual-Phase Meta-Release Cadence for CAMARA APIs

[albertoramosmonagas]

Problem description

The current biannual meta-release cadence (Spring and Fall) treats all API versions equally, regardless of maturity level. This structure creates friction for early-stage APIs and operational fatigue for stable APIs, which require repeated validation and integration across release cycles.

Most operators delay implementation until APIs are stable, while the current cadence enforces redundant efforts on both early adopters (during sandbox phase) and broader deployers (post-stabilization). The lack of formal lifecycle distinction contributes to version fragmentation and inconsistent adoption.

---

Possible evolution

Introduce a dual-phase cadence that distinguishes explicitly between:

• Sandbox Phase (0.x versions): APIs can be released iteratively year-round for early testing and validation, independently of meta-releases.
• Stable Phase (1.x+ versions): APIs are aligned with official meta-releases (Spring or Fall), with a preference for stable releases in Fall.

Stabilization criteria, versioning rules (mandatory/optional/breaking), and patching procedures would be formalized per lifecycle phase. Commonalities and ICM would follow a structured Spring release to prepare for Fall API publication.

---

Alternative solution

Instead of adopting a formal dual-phase cadence, the existing meta-release process could be retained with improved documentation and clearer guidelines for sandbox/stable maturity levels. However, this would not fully address operator alignment, release fatigue, or the need for structured lifecycle planning across CAMARA.

---

Additional context

• Based on Q2 2025 GSMA deployment data, operator adoption strongly favors stable versions, reinforcing the need for phased lifecycle treatment.
• This proposal aligns with TM Forum lifecycle concepts (“obsolete”, “retired”, etc.) and ongoing CAMARA internal practices.
• Dual-phase model improves: Operator coordination and upgrade planning, predictability and support cycles, reduction of redundant validation for early adopters, and a transition plan is outlined from Fall 2025 to Spring/Fall 2026 meta-releases, preserving meta-release anchors while enabling incremental evolution.

Proposal to shift meta-release cadence-CAMARA short version - v1.pptx

[albertoramosmonagas]

During the 2025‑09‑16 meeting of the Know Your Customer group, several members expressed general support for the dual-phase cadence proposal, with no objections raised.

• KDDI (@ToshiWakayama-KDDI ) expressed clear support for the overall model, including the option of having only one meta-release per year. They noted that aligning API development with frequent Commonalities/ICM updates is currently challenging, and the dual-phase model would help reduce this complexity. However, they pointed out the need for a transition phase for APIs that are already commercially implemented but not yet declared "stable". For these cases, breaking changes should be avoided, as the API is effectively between Sandbox and Stable.

• TIM (@FabrizioMoggio) was also supportive but emphasized the need for more clarity on specific implementation details. He agreed with the idea of separating Spring (Commonalities/ICM) and Fall (Stable APIs) to reduce unnecessary workload. Fabrizio also proposed that a Stable API should meet three conditions:

1. The API group considers the spec mature;
2. At least two operators have commercially deployed it;
3. One operator has passed GSMA certification with a complete set of test scenarios.
   Toshi confirmed agreement with these stability criteria.

• DT (@rartych) added support for the Spring/Fall separation, noting that it was also well received by Fabrizio. This reinforces the alignment between operator expectations and the cadence proposal.

In summary, the overall direction was positively received. The main areas requiring refinement include: how to handle transitional APIs that are not formally stable but already deployed, clearer criteria for stability, and ensuring the governance model remains practical.

🔗 Discussion link: camaraproject/KnowYourCustomerMatch#35

[albertoramosmonagas]

Hi @hdamker & @tanjadegroot,

As per the TSC action item “Analysis of impact on existing documents in Governance and Release Management” (2025-09-18 TSC Minutes), this analysis has been carried out.

In addition, the review has also covered Commonalities and Identity & Consent Management. The results are compiled in the attached PPT, currently in draft form, pending further discussion with the relevant groups and incorporation of feedback gathered through the issue.

[hdamker]

@albertoramosmonagas would it be possible to convert the results of the analysis onto a wiki page or as a supplementary document in markdown in a PR? I don't think that all this text will ever presented with these details, but we need an offline review and possibility to comment on it. Formally: if this document should be a guideline it must be in markdown according to our Governance.

Beyond that: the task was to analyze the Governance documents ... it might be better if the working groups analyze the consequences for their artifacts themselves. At least they must be able to review and change the statements (I wouldn't call them guidelines, as not binding), therefore the need for the request in the first paragraph.

[albertoramosmonagas]

Hi @hdamker,

You're right. It was one of the first formats I thought of, but I wasn't sure which was the best consumable. This document is a proposal of the points that would need to be modified in each group and in each document (both GitHub and wiki). I'll remove the document from my last message, and create a wiki page, and make it clear that it's a draft proposal pending validation by the groups.

Edit: Wiki page created with the consequences for their artifacts themselves.

[albertoramosmonagas]

Hi @hdamker,

One question: since the proposal has already been accepted by TSC and implemented by release management, is it necessary to keep this issue open?

[hdamker]

@albertoramosmonagas the approach is indeed accepted and already implemented in ReleaseManagement. Just in case there are remaining points from your wiki page I propose to create them as separate, new issues, and then close here.

[albertoramosmonagas]

Hi @hdamker, on the wiki page, I had proposed changes by document/group. If we ultimately want to update the documentation based on this, I think creating new, separate issues might be the best approach, both for dividing the work and defining the scope, but I'm not sure if we need to approve this document beforehand because it has many comments (unresolved, but addressed)