Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 6 Next »

This page holds proposals for new GitHub issues in the Release Management repo.

Proposals to close the existing issues are provided here: Open Issues Consolidated

Multiple APIs in one API Sub-project

Issue: 

if multiple API endpoints are managed in one API sub project but in separate OAS definition files, each endpoint can evolve separately, but the release packages will mix-up the release of evolutions of these API endpoints.


Proposal:

Put each API endpoint in its own API sub-project such that individual release packages can be created for each API endpoint.

  • Request API projects that contain multiple APIs to create separate sub-projects
  • Add a confluence page linking the APIs of the same "family" to the CAMARA wiki.


Details:

The notion of API family will not be managed as part of release management. CAMARA releases only consider API versions.

It is recommended to have one API per API sub-project to facilitate the release management and versioning of APIs.

If multiple API are managed in one API Sub-project, each API file shall have its own folder, such that release packages can be created with a focus on a specific API. The API name and the API version of this API shall be used in the naming of the API version tag and API version release package. However, as the release package will also include all other APIs of the Sub-project, this may lead to confusion.

An API Sub-project may also decided to release all APIs in the same API family always at the same time with the same API version. In this case,

  • all API files in the release must have the same API version.
  • instead of the API name, the API Sub-project name shall be used in the API version tag and the API version release package name.

If later on one API of the API family requires a separate evolution with its own version number, then this API shall be put in its own API Sub-project.


API Groupings:

The grouping of APIs into families or other groupings, e.g. by related working groups, can be done easily using a CAMARA wiki page.

This will reduce the number of meetings and reporting load with the increasing number of APIs, and facilitate moving APIs from one family or group to another, or combining APIs from multiple families into into into family.

See also Herbert's proposal here: Proposal to establish API Families as Working Groups across API Sub Projects · Issue #7 · camaraproject/ReleaseManagement (github.com)




  • No labels