Skip to content

Release r2.2 (M4 Fall25)#105

Merged
stroncoso-quobis merged 13 commits intocamaraproject:mainfrom
stroncoso-quobis:release-r22
Sep 23, 2025
Merged

Release r2.2 (M4 Fall25)#105
stroncoso-quobis merged 13 commits intocamaraproject:mainfrom
stroncoso-quobis:release-r22

Conversation

@stroncoso-quobis
Copy link
Collaborator

@stroncoso-quobis stroncoso-quobis commented Aug 29, 2025

What type of PR is this?

Add one of the following kinds:

  • subproject management

What this PR does / why we need it:

Stable release for WebRTC APIs - release 2.2

  • Included on Fall25 meta-release
  • Fixes issues detected during testing, and code review

Which issue(s) this PR fixes:

Fixes #96
Fixes #115

Special notes for reviewers:

Included PRs since release-candidate

Changelog input

 release-notes
- doc: API & COMMs version bump for release r2.2
- doc: README update for release r2.2
- doc: CHANGELOG update for release r2.2
- doc: Swagger r2.1 (rc) links on CHANGELOG

Additional documentation

docs
- Updated API readiness files to identify r2.2 and ICM/COMMs r3.3

@stroncoso-quobis stroncoso-quobis added the subproject management Indicating issues with subproject repository or release management process label Aug 29, 2025
@hdamker hdamker changed the title Release r22 (meta-release Fall25 stable) Release r2.2 (M4 Fall25) Aug 30, 2025
Copy link
Contributor

@hdamker hdamker left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Must fix:
The server URL in all YAML and .feature files doesn't match the API version.

For example in webrtc-events:

Description: Server URL version v0.2rc1 doesn't match API version 0.2.0
Location: servers[0].url
Fix: Update server URL to end with /v0.2


webrtc-events - line 722-725: the link into Commonalities within the definition of SubscriptionId is outdated (going to a deprecated document). Use instead the definition as in https://github.com/camaraproject/Commonalities/blob/main/artifacts/camara-cloudevents/event-subscription-template.yaml:

    SubscriptionId:
      type: string
      description: The unique identifier of the subscription in the scope of the subscription manager. When this information is contained within an event notification, this concept SHALL be referred as `subscriptionId` as per [Commonalities Event Notification Model](/documentation/API-design-guidelines.md#122-event-notification).
      example: qs15-h556-rt89-1298

This is also a bug in Commonalities (issue camaraproject/Commonalities#531 created). I propose as short-term solution the definition from sim-swap-subscription:

    SubscriptionId:
      type: string
      description: The unique identifier of the subscription in the scope of the subscription manager. When this information is contained within an event notification, this concept SHALL be referred as subscriptionId as per Commonalities Event Notification Model.
      example: qs15-h556-rt89-1298

Copy link
Contributor

@hdamker hdamker left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should fix (could be done later, non-breaking changes):

Use in all three YAML files the same ErrorInfo definition, with the order status -> code -> message, currently there are different versions with different order of the properties.

Use the latest and fixed version of the definition from https://github.com/camaraproject/Commonalities/blob/main/artifacts/CAMARA_common.yaml (please be aware that CAMARA_common.yaml got fixed after r3.3, it is now aligned with the API Design Guide in r3.3):

    ErrorInfo:
      type: object
      required:
        - status
        - code
        - message
      properties:
        status:
          type: integer
          description: HTTP response status code
        code:
          type: string
          description: A human-readable code to describe the error
        message:
          type: string
          description: A human-readable description of what the event represents 

Multiple schema names are not following the PascalCase convention (in webrtc-registration.yaml):

  • regSessionRequest → should be RegSessionRequest
  • regSessionResponse → should be RegSessionResponse
  • regSessionUpdate → should be RegSessionUpdate

Maybe as well the following ones, but that's questionable:

  • WrtcSDPDescriptor → should be WrtcSdpDescriptor (in both webrtc-call-handling and webrtc-events)
  • HTTPSubscriptionRequest → should be HttpSubscriptionRequest
  • HTTPSubscriptionResponse → should be HttpSubscriptionResponse
  • HTTPSettings → should be HttpSettings

Copy link
Contributor

@hdamker hdamker left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You may want to consider:

The headers of the sections # Authorization and authentication and # Additional CAMARA error responses differ from the templates. On the one side does that raise issues of our release review script (as it does not find the sections, see full results here), on the other side are these sections with that differently formatted than in other APIs of the meta-release. As the section itself are there this is not a critical issue.

If you want to fix that:

## 4. Authorization and authentication -> # Authorization and authentication
## 5. Additional CAMARA error responses -> # Additional CAMARA error responses


Test file names are not matching in multiple cases not with the operationIds within the API file (e.g. -deleteSession instead of -deleteSessionById That isn't mandatory to fix as there could reasons for other name choices.

But you might want to fix the typo in webrtc-registration-deleteRegsitartionById.feature (should be deleteRegistrationById).

Copy link
Contributor

@hdamker hdamker left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The remaining points found during checks along camaraproject/ReleaseManagement#322

@hdamker
Copy link
Contributor

hdamker commented Sep 12, 2025

@stroncoso-quobis please find my review results above. The critical points should be easy to fix, also the other points. If you don't want to fix a certain topic now, you can also create issues for the next release.

@tanjadegroot
Copy link
Contributor

@stroncoso-quobis Hi Santiago, team, will you be able to release the API before tomorrow's TSC meeting at 4PM CEST ?
we want to declare the M4/M5 tomorrow.
many thanks !

@tanjadegroot
Copy link
Contributor

PS. it would be great if you could include the fix on ErrorInfo schema in the yaml files) as indicated above, as all other Fall25 API have fixed it :-)

@stroncoso-quobis
Copy link
Collaborator Author

Hi @tanjadegroot , hard deadline, I'm little overloaded this week, it started fine, but I had really no-time to dedicate to this, so I will have some time this late afternoon.

Anyway, I will do my best to get everything ready. Attending to the @hdamker comment, we need a separate PR for ErrorInfo fix, I will try to get the time for the PR, notify my colleagues for PR approve, merge and notify you back...

As said, I will do my best 💪

@tanjadegroot
Copy link
Contributor

tanjadegroot commented Sep 18, 2025

Hi @tanjadegroot , hard deadline, I'm little overloaded this week, it started fine, but I had really no-time to dedicate to this, so I will have some time this late afternoon.

Anyway, I will do my best to get everything ready. Attending to the @hdamker comment, we need a separate PR for ErrorInfo fix, I will try to get the time for the PR, notify my colleagues for PR approve, merge and notify you back...

As said, I will do my best 💪

Thanks very much Santiago @stroncoso-quobis ! I think we can then consider the API will be release today. Great news.
Thanks to the team for all the efforts. !!

Copy link
Collaborator Author

@stroncoso-quobis stroncoso-quobis left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Review of CHANGELOG and README done. Letting YAML titles and PascalCase object naming as fixes for future PRs.

@stroncoso-quobis
Copy link
Collaborator Author

Hi @hdamker , @tanjadegroot ,

Main fixes done here: CHANGELOG, README & API Readiness files. 2f0b5c0
Also, ErrorInfo object updated at a separated PR #113

I will let as bugs pending to fix the other comments provided, I will create GitHub issues for them:

  • PascalCase at objects review.
  • Doc tiltles at YAML.
  • OperationID at testing files

Most of them come from original commonalites not properly aligned. I really would appreciate a sooner review, that I would have more time to fix them. But them seem minor bugs, we will fix them soon.
Anyway, thanks for your support, review and detailed work! Really appreciated. 🙇

Let me know if something extra is needed and further steps to publish the release.

Best regards,

Copy link
Contributor

@hdamker hdamker left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@stroncoso-quobis thanks for the fixes, it looks good to merge, and I'm fine with your decision to postpone further fixes. I'm also ok that the PR is currently not in sync with main, I have reviewed the three commits separately.

Thanks for your understanding regarding the timing we will do next time better (🤞 that with more time available the reviews will distribute better and not still all coming at the deadline).

@hdamker
Copy link
Contributor

hdamker commented Sep 18, 2025

@stroncoso-quobis the final check has shown, that you have overseen the first must fix from my comments:

The server URL in all YAML and .feature files doesn't match the API version.

For example in webrtc-events:

Description: Server URL version v0.2rc1 doesn't match API version 0.2.0
Location: servers[0].url
Fix: Update server URL to end with /v0.2

That's in all .feature files one small change ... remove the rc1 from the version in all resource lines, e.g.:

`And the resource "/webrtc-call-handling/v0.3rc1/sessions"`->     
`And the resource "/webrtc-call-handling/v0.3/sessions"`

This was referenced Sep 19, 2025
Copy link
Collaborator Author

@stroncoso-quobis stroncoso-quobis left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Resolvind outdated conversations and proceding to push changes regarding:

  • README tag links
  • Inline YAML doc titles
  • Server URL (remove rc1 suffix)

I will push ASAP and notify.
Regards,

@stroncoso-quobis
Copy link
Collaborator Author

Hi @hdamker , @tanjadegroot

Changes applied to solve critical issue:

  • Fixed tag links ( 38c1c2d )
  • YAML inline doc title alignment ( 2289d0f )
  • Server path updated to stable for YAML and FEATURE test files ( 27554cf )

Also:

But I wrote 103 instead of 113, the CHANGELOG message is ok, but the commit message wrong. Should I force push the correct commit message?

Best regards

@hdamker
Copy link
Contributor

hdamker commented Sep 22, 2025

@stroncoso-quobis thanks fa lot or the corrections, almost done now and I considered already to approve, but maybe you want to change the following points:

  • webrtc-events.yaml: The Authorization and authentication text is not the latest (e.g. API Client -> API consumer) - would be great if you can just copy it over from one of the other APIs
  • PR #88 is actually not a PR, but the issue for PR 88 commonalities 060 #90. People can easily follow the links to the PR, therefore also ok to keep it if you prefer
  • ErrInfo schema definition:
    • webrtc-events has the correct order status -> code -> message, while
    • webrtc-registration and webrtc-call-handling have the (wrong) the reversed order message -> code -> status.

The last point can for sure be considered as a cosmetic and potentially technical irrelevant issue, but these are last two APIs in the complete meta-release of 60 APIs which have this reversed order (and all your examples are in the correct order). Would be good if you also across your own APIs use the same order in the schema. We can also not be completely sure if some code generators might not get irritated by that.

P.S.: I don't care about typos in commit messages.

@hdamker
Copy link
Contributor

hdamker commented Sep 23, 2025

@stroncoso-quobis ready for final review/approval or will you address ErrInfo as well?

@stroncoso-quobis
Copy link
Collaborator Author

stroncoso-quobis commented Sep 23, 2025

Hi @hdamker ,
Currently fixing ErrorInfo, it produces a conflict on the main, so I'm solving before push.

@stroncoso-quobis
Copy link
Collaborator Author

stroncoso-quobis commented Sep 23, 2025

Ok @hdamker ,
It seems ready to go. ErrorInfo fixed at c2d9296 and conflicts resolve at a3ab467.
Let me know if it is ok for release.

Best regards,

@hdamker
Copy link
Contributor

hdamker commented Sep 23, 2025

Ok @hdamker , It seems ready to go. ErrorInfo fixed at c2d9296 and conflicts resolve at a3ab467. Let me know if it is ok for release.

Great @stroncoso-quobis. Seems that you had done the need corrections already within #113 ... just not visible within the release PR as it wasn't updated (btw was the PR 113 more aligned with https://github.com/camaraproject/Commonalities/blob/main/artifacts/CAMARA_common.yaml, but that's now really nits).

I will approve and hope you can create merge and create the release today before 15:00 UTC (start of the Release Management call).

Copy link
Contributor

@hdamker hdamker left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Approved on behalf of Release Management 👏

Next steps for the team:

  • PR merged (by API repository codeowner)
  • Release created within GitHub (by API repository codeowner)
  • Release Tracker updated (with creation date of the release and the release tag link)

@stroncoso-quobis
Copy link
Collaborator Author

Thansk @hdamker ,
Seems that I need a @camaraproject/web-rtc_codeowner approval.
As soon as approved, I will merge it.

Best regards,

@tanjadegroot
Copy link
Contributor

Hi Team, @stroncoso-quobis, please merge, create the release and update the release trackers !!
thanks a lot :-)

@stroncoso-quobis stroncoso-quobis merged commit 7d9f8af into camaraproject:main Sep 23, 2025
2 checks passed
@stroncoso-quobis
Copy link
Collaborator Author

Merged!

Release created here: https://github.com/camaraproject/WebRTC/releases/latest (r2.2)
release-tracker update in progress -> https://lf-camaraproject.atlassian.net/wiki/spaces/CAM/pages/14564612/WebRTC+API+Release+Tracking

@tanjadegroot I will update ASAP
BR,

@stroncoso-quobis
Copy link
Collaborator Author

Hi @tanjadegroot ,

Let me know if you need anything from my side
Best regards,

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

subproject management Indicating issues with subproject repository or release management process

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Doc titles at YAML Some incorrect links at r2.1 CHANGELOG file

4 participants