Page History

...

An API Sub-project can create as many initial or alpha API versions as they want during API development in preparation for the release.

For API version > v0versions with x>0, the next API version number is defined and does NOT change during API development and release preparation. Only the API version extensions and their numbers may change. 

...

• At the M5 release milestone, the final API version (without any extension) is created in its branch and with its release package, and included in the meta-release.
• Inclusion in a meta release is done by adding the required information for the API version on the meta-release page.

Updating an API

Updates to a public-release API version need to be carefully planned.

...

• changes in the major number when creating non-backward compatible changes / breaking changes to the API
• changes in the minor number when creating backward compatible changes to the API
• changes in the patch number when correcting an error of the API

...

• Develop the 1.1.0 update on the main branch
• Once sufficiently stable, create a new branch API version api-1.1.0-alpha.1 .  by tagging the main branch
• Several intermediate alpha branches may be created, with or without release packages,
• Then one or more intermediate release-candidate API versions (rc branches + release packages) may be created (see example table below).
• The last release-candidate API version will be proposed for meta-release. 
• After meta-release approval, create the api-1.1.0 branch and release package ("latest") for the new public-release API version 1.1.0.

API family

Meta-release approval for an API version

• To be approved for meta release, the API version must provide all the public items of the release checklist and meet the meta release acceptance criteria.
• The API Sub-project shall announce ther intention for public-release API vesion by documenting the references to the relevant release-candidate API version on the meta release page.
• After check by the release management team, approval is documents there.
• Once approved the API Sub-project shall create the public-release API version and its API version assets.
• Finally the API sub-project shall update the meta-release page with the reference to the public-release API version.

API family

The notion of API family will not be managed as part of release management. CAMARA releases only consider API versions.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.

...

NOTE: This proposal can be fed back into GitHub Commonalities project as needed.

The following table identifies the items that need to be provided for an API version for a particular release.

...

In addition the following are the release API version assets that need to be provided to support the release of an API version:

Examples

The following are examples of the API release asset naming for the various API versions throughout the API version's lifecycle. 

API version 0.y.z (initial API development and first release)

API version x.y.z (x>0) (public-release API updates)

...

Minor update of API version

Patch update of API version

Major update of API version