...
- 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:
...
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.
...
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 | 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. | |
? | API release numbering conventions | This is verified using the information on the release tracker page. |
Protected branches enabled | Do we still need this ? As there are no more release publication branches, this would only apply to maintenance release branches ? | |
? | 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 release assets | alpha | release-candidate | public-release | |
initial | stable | ||||
Linting rules enabled | Y | Y | Y | Y | |
Maintainers doc (from at least 3 distinct companies) | Y | Y | Y | Y | |
Codeowners doc (from at least 3 distinct companies) | Y | Y | Y | Y | |
? | API release numbering conventions followed | Y | Y | Y | Y |
Protected branches enabled | Y | Y | Y | Y | |
? | Release-candidate API version tested in at least 2 operator implementations | N | N | Y | Y |
? | initial public-release API version certified and launched in at least 2 operators is needed to become stable | N | N | N | Y |