Merge pull request #2 from nokia/99-updates-per-feedback

99 updates per feedback

documentation/API_Release_Guidelines.md

@@ -138,6 +138,12 @@ A (pre-)release PR provides only the following changes: 
 
 In case a patch update of a public API version x.y.z is required, the patched public API version x.y.z+1 shall be created through a maintenance release on a separate branch referred to as a maintenance branch. 
 
+The name of the maintenance branch shall be "maintenance-xy" (for a patch x.y.z+1 of released API x.y.z). Any further patches shall be done on this same branch. 
+
+Preferably, a maintenance release shall be merged into the main branch as soon as possible.
+
+The maintenance release shall replace the public API and its API release tracker shall be updated. This implies to update the API release tracker (page) name with the patch version and adding the release tag link and the date of publication.
+
 NOTE: a patch is the only case for which a separate branch is created and maintained within the API repository (as pull requests should be prepared within forks of the API repository, c.f. [Governance/CONTRIBUTING.md](https://github.com/camaraproject/Governance/blob/main/CONTRIBUTING.md))
 
 ## Example of the API release process
@@ -153,3 +159,4 @@ To release a MINOR update of a public API version 1.0.0, resulting in the releas
 * When the API version is ready for public release, create the release PR that sets the public API version to 1.1.0. (this PR minimally removes the rc extensions from the version and URL fields in the API yaml file and assures all API release assets are available as per the API readiness checklist).
 * After release PR approval, create the release rx.n+1 and update the API release tracker.
 * The approved public API version 1.1.0 will be included in the meta-release.
+* If a patch is provided for the released API, it shall be declared asthe latest release, and the information shall be published on the existing API release tracker.