enhance v0.4.1 to follow latest CAMARA guidelines

[maheshc01]

Problem description
v0.4.1 API spec is not compliant with latest CAMARA guidelines specifically RequestRoamingStatus schema. Rather than wait for v0.5 which has lot more functionality we would like to enhance v0.4.1 to comply with latest standards and create anyother tagged version v0.4.2.
This is for a potential multi operator demo.
We dont have time to wait till v0.5 is finalized but at the same time dont want to use an older tagged version which will not support forward compatibility due to schema changes.

Possible evolution

Alternative solution

Additional context

[hdamker]

@maheshc01 I understand the underlying request and would be also in favor of more often releases with smaller amount of changes.

If I understand you right you would like to have a release with the schema changes introduced by the introduction of the glossary (e.g. Ue -> Device, as requested within #52). This change was done together with the introduction of notification/subscriptions within the PR #31, so there is no clear commit which could be tagged only for this change and not including the event subscriptions. And the event subscriptions had to be updated in the meantime updated with #75 to adhere to the latest guidelines with CloudEvents (which was the main reason for the delay of the release).

A release even with only the change of the schema wouldn't be a patch release of 0.4.1 as this is a significant non-compatible change. It must update the minor version to distinct it from 0.4.1

One option would be to create a release-0.5.0 branch from release-0.4.1 branch and cherry-pick only the changes from main which are needed to ensure backward compatibility with the upcoming release including the enhanced functionality (which then would get v0.6.0). But I doubt that this "interim release" will be faster done than the already planned release candidate. In addition it would have still a very limited functionality and the effort to create it would delay the planned release further. It would have made sense earlier this year.

The other - and maybe better option - could be to expedite the planned v0.5.0 and take the release candidate as the base ... and implement for the demo only the needed functionality (e.g. not the notification/subscriptions).

[maheshc01]

Hi @hdamker. Confirming that your understanding of the problem statement i created above is accurate.
Thank you for your analysis and laying out the possible options. I was hoping that creating a new tagged version of v0.4.2 with just the schema changes (#52 ) would be a feasible solution but i understand your point of this being a non-compatible change.

The multi operator demo i mentioned is in the context of market champion initiative in opengateway and we are looking to finalize the API version to use ASAP.

Do you have any timelines on when v0.5 will be created?
(I am not active on the Device status calls, so apologies in advance if i am asking for information which was already discussed/shared).

[ChrisC-att]

Confirming this request would be needed from AT&T side for the multi operator demo mentionned above.

[akoshunyadi]

Currently there is one PR under review, after merging it we will create the 0.5.0-RC, I'm expecting it within the next 2 weeks

[hdamker]

@maheshc01 I propose to close the issue.

Release candidate v0.5.0 is available and should be the base for development work and for feedback from your multi operator demo into the community.

[maheshc01]

@hdamker yes, i am good with closing the issue.
We have been able to agree on the path forward for the multi operator demo.
Thank you!