2025-04-15 Release WG Minutes
Community Attendees:
Community Attendees:
LF Staff:
Agenda
The project's Antitrust Policy is linked from the LF and project websites. The policy is important when multiple companies, including potential industry competitors, are participating in meetings. Please review it, and if you have any questions, please contact your company’s legal counsel. Members of the LF may contact Andrew Updegrove at the firm Gesmer Updegrove LLP, which provides legal counsel to the LF.
Action Items Review
Fall25 meta-release
Issues review
AOB
Minutes
Action Items Review
See action items list here: https://lf-camaraproject.atlassian.net/wiki/spaces/CAM/pages/14552660
Fall25 meta-release (https://lf-camaraproject.atlassian.net/wiki/x/FQApAg?atlOrigin=eyJpIjoiZWIyZGY3YWY4Yzk2NGQxNWFjODlkZGNmYmFmYTVkMDIiLCJwIjoiYyJ9)
M1
Target date: April 15th, proposed to shift to April 29th in the TSC on April 3rd.
There was no quorum in that TSC meeting, but no opposition from the people present. It was decided to put the decision to the next TSC meeting on April 17th.
Commonalities: scope issue #423 is ongoing: error updates / subscriptions/notifications; further work (not impacting APIs (e.g. linting) will be done for M2)
@Tanja de Groot update of the API readiness checklist with additional reference to subscription guidelines on Confluence with Commonalities alpha release publication.
ICM 0.4.0: scope issue #275 is ongoing.
Release Management to update its Confluence and GitHub artefacts for the Fall25 (alpha release at M1)
@Herbert Damker after TSC on April 17 confirms the new M1 date, send email to codeowners with this info and request for API release tracker creation.
Issues review
Issues · camaraproject/ReleaseManagement
issue 200
Update of the API readiness checklist in Github and in Confluence
Update of API description to be done between M3 and M4
M3 review issues will have an addition item to check that the checklist version has been updated
M4 review will check the actual content
event structure versioning (Discuss the versioning in event structure · Issue #157 · camaraproject/ReleaseManagement)
event structure breaking changes implies event structure MAJOR version update and and API MAJOR version update, but not the inverse. only when from v0 to v1
event structure version has only one (MAJOR) version number in the event type
for stable API v1 also event structure version should go to v1 - stable API
option 1: during v0 dev of API, the event structure can keep v0 even if changes - distinction is on the API version
option 2: change the event number in case of breaking change, but that will increase the event version, beyond the MAJOR API version number.
@Tanja de Groot Put the above in the issue and request comments.
Test result statement for stable APIs within Spring25 meta-release (M4) · Issue #161 · camaraproject/ReleaseManagement - target date for closure: Apr 29, 2025
AOB
repo creation automation was presented by Herbert.