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 7 Next »

READY FOR REVIEW

API Sub Projects are used to develop and support releasing APIs.

  • One API Sub Project ideally contains one API or a small set of closely related APIs. 
  • A release includes all the APIs of the API Sub Project. 
  • Hence a public-release can only be created when all APIs in the API Sub Project have at least an initial public-release API version.

API Sub Project maturity status

API Sub-projects may have one of the follow maturity status:

  • Sandbox
  • Incubated

By default an API Sub Project has the Sandbox maturity status.

An API Sub Project needs to minimally respect the following requirements to obtain the Incubated maturity status:

  • It participated in at least 1 meta-release cycle
  • It is managed through regular scheduled meetings with meeting minutes being provided.
  • It has adopted LF tools (Zoom, wiki, ...) and uses them according to the CAMARA guidelines.

The maturity status is determined by the TSC based on these and the below requirements.

Sandbox API Sub-project 

A Sandbox API Sub Project can release only initial public-release API versions (0.x.y).

Its released API versions will be listed as part of a meta-release if the Release Process was applied to all of its contained APIs.

Incubated API Sub-project

Incubation is the verification and approval of the Incubated status of an API Sub Project. Incubation can happen as part of a release cycle.

To get the Incubated status the API Sub Project needs to meet the following requirements:

  • The API Sub Project has at least one API released with an initial public-release version (0.x.y)
  • The Sandbox API Sub Project has stated the goal to become incubated in the beginning of the release cycle (on relevant API release tracker pages)
  • The Incubated status is approved by the TSC

An Incubated API Sub Project can manage and evolve in parallel APIs with stable versions (1.x.y) and initial versions (0.x.y). 

An Incubated API Sub Projects has to follow the meta-release cycle for all included APIs.


API Sub-project classification (moved from API readiness checklist)

The following table explains each of the criteria to be respected by an API Sub-project to be classified as Sandbox or Incubating.

Nr

API Sub-project classification criteria

Explanation


Linting rules enabled

The linting rules provided by Commonalities that are successfully executed against the OAS API definition file. The output report of the linting shall be provided.


Maintainers (from at least 3 distinct companies)

This needs to be checked and confirmed by the API Sub Project team in the API Sub-project home/MAINTAINERS.md file. 


Codeowners (from at least 3 distinct companies)

This needs to be checked and confirmed by the API Sub Project team in the API Sub-project home/CODEOWNERS file.


Protected branches enabled

Required for incubated API Sub Projects


User stories

Required for incubated API Sub Projects

?

Release-candidate API version tested in at least 2 operator implementations

References to at least 2 operator implementations of the API are provided. In which form shall this information be provided ? Links to websites could be added to the API release tracker.

?

initial public-release API version certified and launched in at least 2 operators is needed to become stable

References to at least 2 certifications and at least 2 commercial operator implementations of the API are provided. In which form shall this information be provided ? Links to websites could be added to the API release tracker.


The following table is the API readiness checklist of the assets that need to be provided for the release of an given API version. 

Nr

API Sub-project classification criteria

API Sub-project



Sandbox

Incubated


Linting rules as defined by Commonalities enabled to check every Pull Request

O

M


MAINTAINERS.md file with at least one Maintainer (typical the API proposal owner)

M

M


Maintainers from at least 3 distinct companies (defined within MAINTAINERS.md)

O

M


CODEOWNER file with at least one Codeowner

M

M


Codeowners from at least 2 distinct companies (3 recommended)

O

M

?

API release numbering conventions followed

Y

Y


Protected branches enabled

Y

Y

?

Release-candidate API version tested in at least 2 operator implementations

Y

Y


At least one public-release API version in a Sandbox has to be launched by n operators in m markets in production is required to become Incubated [n and m tbd further]

N/A

M



  • No labels