Risk for Fall25 releases if APIs stay together in EdgeCloud repository - urgent proposal to split into proper API repositories #372
Description
Problem description
It is great to see the activity within the repository and the ambition to get three APIs ready for the Fall25 meta-release as stated in camaraproject/OptimalEdgeDiscovery#8, camaraproject/ApplicationEndpointDiscovery#8, and #353.
But I see a significant risk that it might not possible to achieve this goal if the plan is to release this repository (EdgeCloud) according to guidelines of the Release Management working group.
As a release can always done only for the complete repository, all API definitions within the repository must be ready for there release candidate release until the M3 milestone (June 21st), which means that for each API (including the one not planned for Fall25 yet!) the requirements within the API Readiness Checklist must be fulfilled:
- API definitions consistent and aligned with Commonalities (0.6.0) and ICM Guidelines (0.4.0)
- API documentation (embedded into the API definition files)
- Basic API test cases & documentation (.feature files)
That must be also achieved for the API(s) within the repository which are not yet planned for Fall25 must be brought to this level, as it is NOT possible to create a release if any of the APIs in the repositories is still work in progress or similar. This create a severe risk for the Fall25 release of EdgeCloud APIs as it is enough that one of the APIs does not make it until the relevant milestones. Due to the common repository then all planned APIs can't be released.
Other API Repositories (e.g. DeviceStatus or KnowYourCustomer) has felt this risk and time pressure in the past and have therefore decided to split their "multi-"API repositories into multiple one with one or two APIs. The advantage is that the APIs can be released independently of each other and does not block each other in case they are not getting ready in time.
Expected action
Request seperate repositories for the APIs which are planned and prioritized for the Fall25 release (a short issue similar to camaraproject/APIBacklog#213 is enough for that). I would be more than happy to expedite the creation of these repositories (e.g. beginning of next week) and help with the migration of the assets into the new repositories.
Important is to define for each repository a group of codeowners already within the issue to allow the immediate creation of the repositories. For the maintainer group my recommendation would be to use the same group as currently here in EdgeCloud (maybe updated?) to express the common responsibility of the EdgeCloud Sub Project for these repositories.
Additional context
- The Sub Project EdgeCloud, including meetings, wiki page, meeting minutes, mailing list will continue to exist (including the APIs SimpleEdgeDiscovery and TrafficInfluence)
- My proposal for the EdgeCloud repository is to follow the same approach as KnowYourCustomer and DeviceStatus ... it will be "frozen" after the API assets are moved out and will be archived after some period (e.g. one year)
- The special situation of the EdgeCloud repository is that it had some "partial" legacy releases in the past, which contained a mix of API definitions, but never a consistent set across the repository. That is how it looks within a report done recently across all repositories.
- New repositories would give each EdgeCloud API the opportunity for a fresh restart and a proper first initial release according to the CAMARA release guidelines which exist since mid of 2024.