TI API dedicated repository

[FabrizioMoggio]

Considering the list of activities here: #282

Once competed those activities, the TI API can have a tagged release.

As suggested here: #295, at that point a specific repository can be created.

For sure it is important to have some Codeowners and Maintainers. Maybe @gunjald, @nicolacdnll?

Please I would like to invite people from the Edge Group to help me carrying on the work on the TI API in the new repository.

Please add you name and role (Codeowners and or Maintainers) in this discussion.

Please note that the TI API is still in the Edge Cloud Family.

I will be Codeowner and Maintainer.

[FabrizioMoggio]

The current PR (#315) provides a set of changes that fix issues on already implemented features and align the TI API with the CAMARA guidelines that were defined for the last Meta Release (Fall24). Before moving forward with adding new feature to the API (Automatic mobility - #218) we could cerate a specific repository for the API. Once the PR is merged.

Some question for @hdamker:

• which is the process to request a specific repository for the TI API?
• about the tagged version you where referencing to (TI API: Changelog #295 (comment)), is it for the single TI API (is this possible?) or for the whole Edge Cloud Family?
• about versioning: now the TI API is WIP, should we move it to Alpha or to RC? (because we are already planning a new feature I suggest to move it to Alpha rather than to RC).

[hdamker]

Hi @FabrizioMoggio,

there is an existing API proposal for the TrafficInfluence API within the API Backlog working group. Therefore it is enough to create a short issue within the API Backlog group to request the (Sandbox) API Repository for the Traffic Influence API . Maybe @jgarciahospital can even create directly the onboarding issue, as I don't see that there is a decision in the API Backlog working group needed, it's more to inform the group.

I'm a little bit concerned about the versioning of the API, and concrete about the title of #315, which is "release 0.9.9". That wouldn't be neither a valid version number for the API as it is not a patch of the previous one as there were a lot of breaking changes since 0.9.x, nor a release number. In general: the PR title should rather describe what the changes are about.

Given that you target still an initial API version (0.x) and don't want to declare it already stable, you can target now 0.10.0, starting with a pre-release of 0.10.0-alpha.1. If you target a stable version then it would be 1.0.0-alpha.1 (prerequisite would be that there was a previous version which is implemented and tested in a network - was that 0.8.1?).

In both cases I would recommend to do the proper pre-release of the alpha version already within the new repository, not here in EdgeCloud (as this would require a coordinated release of all APIs at the same time). The release number would be r1.1.

Regarding the "tagged" version: a tag is only a pointer to a certain commit in the repository, so instead a tag you can also refer back to a concrete commit (the merge commit of #315) when you upload the yaml and test definition as seed code within the new repository. Within the CHANGELOG.md you can then refer back to the PRs here in EdgeCloud to document the version history.

Hope that helps.

[FabrizioMoggio]

@hdamker About the Repo for the TI API: why a "Sandabox"? In my understanding the Sandbox is a simplified Repo to help managing the development for an API that has not yet received the full support. In the case of the TI API we already have a consolidated support and contributor that I hope will join the new Repo that is anyway a Repo linked to the Edge Cloud one. But, probably, I'm missing something :-)

About the title of #315, I decided to adopt that name because the PR was "live" and was continuously updated with new features. This due to the faster pace of my development compared to the pace of the PR approvals. Anyway thank you for the suggestion, I will rename it "Fall24 alignment"

About the release number, I will use 0.10.0-alpha.1 and I will do it in the new Repo as you suggested.

[hdamker]

@hdamker About the Repo for the TI API: why a "Sandbox"?

Because it is not yet an "Incubated Repository", see the definition within ProjectStructureAndRoles:

A Sandbox API Repository is meant for the rapid development of a new API proposal through one or multiple initial API versions (0.x.y) until the first public release of an initial or stable API Version within the context of a CAMARA Meta-release.

The API Repository will belong to the EdgeCloud Sub Project (assuming the team of Maintainers there is agreeing to that) and technically there is no difference to an Incubated API Repository. If you have enough code owners (at least two) I recommend also to enable the branch protection from the beginning.

[FabrizioMoggio]

Sandbox Repository requested: camaraproject/APIBacklog#169

Call for support: any maintainers or codeowners available?

[FabrizioMoggio]

TI API repository created: https://github.com/camaraproject/TrafficInfluence