Release Management: Multiple APIs in one API Sub-project

[javierlozallu]

As mentioned in the meeting we have to comply with the guidelines for releasing multiple APIs in an API sub-project. As this is an open topic I don't think there is anything official but here are some agreements on the discussion:

Problem: If multiple API files are managed in one API Sub-project/repo, then release package will include all APIs, even if they are not intended to be released.

Proposal:

• Develop only one API (file) in one API Sub-Project
• Decouple release name/number from contained API versions

At the moment we have 3 APIs in the Edge Cloud family and 1 API to be created.

Please @Kevsy, update us on this topic.

[Kevsy]

@javierlozallu Sure -

The issue is owned by the CAMARA Release Management Working Group, and the proposals are under discussion here . The Release Management team are working to document the agreed process.

My preference is proposal 2 (Decouple release name/number from contained API versions), and we should also clean the repository of any APIs that have not received recent contributions.

[javierlozallu]

I agree that we need to clean the repository of any APIs that have not received recent contributions. It also seems that the discussion tends to define that the most appropriate option is number 2, so it is necessary to define what changes need to be made and the implications for each API.

@FabrizioMoggio, @gunjald, @nicolacdnll, @ThomasEdgeXR what do you think?

[gunjald]

I also agree that we should clean up the repository that either has not received recent contributions or the ones which we have not yet agreed to take up further without a discussion and agreement within group.

This is just to avoid external readers any confusion what are the APIs those are actually being evolved. As we proceed those earlier contributions can be brought in again following the standard procedures we follow for the new APIs. Specially not we have intents definition and also the key terms harmonized it will be easier to evaluate a new contribution aligned with these terms.

[FabrizioMoggio]

In my understanding we are proceeding with a new Repository for "Ready to be released" APIs such as SimpleEdgeDiscovery. The API is still in the Edge Cloud Family but, for versioning reasons, it gets its own Repository.

@crissancas @gunjald How is SimpleEdgeDiscovery managed inside the Edge Cloud Family in terms of "files and folders"? It will be deleted and a link to the new repository will be created in the WG Home page?

[javierlozallu]

@FabrizioMoggio, yes as is being discussed in the PR - Repository cleanup #235, the proposal is to keep the current work in our repository and new work in the new one, so we have to add the link in the WG Home Page as I proposed in the PR.

As was discussed in the last meeting, the structure folder will be updated so in the API_Definitions will be only the 3 APIs and a general README, and old files will be moved to Supporting Documents.

[javierlozallu]

The new Simple Edge Discovery is empty at the moment, but I guess @Kevsy will upload version 1.0.0 yaml, user story,.... All the files needed to include the API in the fall meta release if I'm not mistaken. Maybe it would be useful if @Kevsy officially presents the new repository at the next meeting (May 21)

[javierlozallu]

Also @Kevsy, could you please specify here that a separate repository is the TSC solution for this issue, so that we can register it for the future.