Browsing Turkish translation

13.

API stability

14.

Summary

15.

Define API stability guarantees for your project. (<link xref="#stability"/>)

16.

Ensure version numbers are changed as appropriate when API changes. (<link xref="#versioning"/>)

17.

API and ABI

18.

At a high level, an API – <em>Application Programming Interface</em> – is the boundary between two components when developing against them. It is closely related to an ABI – <em>Application Binary Interface</em> – which is the boundary at runtime. It defines the possible ways in which other components can interact with a component. More concretely, this normally means the C headers of a library form its API, and compiled library symbols its ABI. The difference between an API and ABI is given by compilation of the code: there are certain things in a C header, such as <code>#define</code>s, which can cause a library’s API to change without changing its ABI. But these differences are mostly academic, and for all practical purposes, API and ABI can be treated interchangeably.

19.

Examples of API-incompatible changes to a C function would be to add a new parameter, change the function’s return type, or remove a parameter.

20.

However, many other parts of a project can form an API. If a daemon exposes itself on D-Bus, the interfaces exported there form an API. Similarly, if a C API is exposed in higher level languages by use of GIR, the GIR file forms another API — if it changes, any higher level code using it must also change.

21.

Other examples of more unusual APIs are configuration file locations and formats, and GSettings schemas. Any changes to these could require code using your library to change.

22.

Stability