View source | Discuss this page | Page history | Printable version   

API change cycle

How to handle if the API check tools raises a problem?

API change acceptance flow

1. An immediate defect is logged and it is assigned to the developer that caused it. If needed, the defect is split into multiple issues.

2. The developer reviews it:

2.a If he made the API change by error, he reverts the change by a commit to PI. The commit should be used to resolve the immediate issue logged to the change. -> Done


2.b The developer adds a comment explaining:

3. DME approves and rejects the exception by simply adding a note to the defect, assigning back to the developer and setting it to status scheduled (since it is now triaged).

4.a If rejected, the developer rolls back the change and implements it in a different way that does not cause an API change. The developer sets the status to resolved when he/she is done.


4.b If approved,

This short info is only possible if the wiki description and/or immediate issue does contain all details which could be interesting to a developer affected by that change.

Fix API check tool

Once the API change is accepted, the developer has to make sure the the api change is not longer raised by the check tools:

For all changes the developer needs a mercurial clone of the api-checks repository:

Then, the right files corresponding to the accepted api change needs to be updated/committed/pushed. This commit should be used to resolve the immediate issue used to track the api problem.

Retrieved from ""

This page has been accessed 2,371 times. This page was last modified on 7 July 2022, at 08:23. Content is available under Creative Commons Attribution-ShareAlike 2.5 Spain License.