Discussion on whether to move number-recycling to Stable status.

[Masa8106]

As discussed during KYC meeting previously, it may be interesting to see if NumberRecycling API can be moved to a stable status regarding how it is adopted and implemented by operators in countries.
Let's discuss here on this including our release planning.

[albertoramosmonagas]

From TEF side, we support moving Number Recycling towards Stable status, provided that the mandatory Stable readiness assets are completed and validated.

The API already shows a reasonable level of market maturity. According to the GSMA Open Gateway Launch Map information available to us, Number Recycling is visible across several markets and operators, including Japan/KDDI, Netherlands/KPN, India/Reliance Jio and Germany/Telefónica, with different public API versions already deployed and including GSMA-certified implementations.

In addition, Number Recycling has already participated in previous CAMARA meta-release cycles and the next one would be its third meta-release participation. This gives a good signal of specification maturity and continued alignment with CAMARA release processes.

I would therefore not see market adoption as a blocker for progressing Number Recycling to Stable. As with the other APIs, the final decision should be based on the Stable Public API readiness checklist: API definition, Commonalities/ICM alignment, API documentation, user stories, basic and enhanced test cases, API description, release plan, etc.

Unless there are unresolved functional issues or expected non-backward-compatible changes, TEF supports targeting Number Recycling for Stable status.

[Masa8106]

I think it is good to move Number Recycling to Stable status.

What I would like to discuss with you is when to do that. We have a plan to adopt some changes, which may be breaking ones in order to align with response table in the whitepaper, into the next release, Sync26. On the other hand, according to a similar discussion in KYC Match here, there is an opinion to prefer avoiding compatibility breaking at the time of changing to Stable status.

So I think there is two approaches:
(1) Although there will be big changes, Sync26 will be Stable version.
(2) As there will be big changes, we will skip to move Sync26 to Stable version and Sync27 will be Stable version.

This is an open minded question. I would like to select an approach which are preferable for us. Thank you.

[albertoramosmonagas]

Personally, I don’t have a strong opinion on this. From a technical point of view, the version change from 0.x to 1.x is a major one, so I understand that if we go with option 1, there shouldn’t really be a problem. But I’m open to both options. My fear is that we’ll miss the opportunity presented by this meta-release and then, come Sync27, we’ll be having this discussion all over again because it’s never the right time to make the change.