|
|
11.
|
|
|
2015
|
|
|
(itstool) path: credit/years
|
|
|
|
|
(no translation yet)
|
|
|
|
Located in
C/api-stability.page:12
C/async-programming.page:13
C/databases.page:13
C/documentation.page:18
C/file-system.page:13
C/gerror.page:13
C/glist.page:13
C/index.page:23
C/introspection.page:12
C/logging.page:13
C/memory-management.page:12
C/parallel-installability.page:20
C/preconditions.page:13
C/threading.page:13
C/tooling.page:12
C/unit-testing.page:12
C/version-control.page:12
C/versioning.page:12
|
|
|
12.
|
|
|
Backwards compatibility in APIs
|
|
|
(itstool) path: info/desc
|
|
|
|
|
(no translation yet)
|
|
|
|
Located in
C/api-stability.page:17
|
|
|
13.
|
|
|
API stability
|
|
|
(itstool) path: page/title
|
|
|
|
|
(no translation yet)
|
|
|
|
Located in
C/api-stability.page:20
|
|
|
14.
|
|
|
Summary
|
|
|
(itstool) path: synopsis/title
|
|
|
|
|
(no translation yet)
|
|
|
|
Located in
C/api-stability.page:23
C/async-programming.page:26
C/databases.page:24
C/documentation.page:32
C/file-system.page:24
C/introspection.page:23
C/logging.page:26
C/main-contexts.page:27
C/memory-management.page:65
C/namespacing.page:25
C/parallel-installability.page:33
C/threading.page:24
C/tooling.page:45
C/unit-testing.page:23
C/version-control.page:23
C/versioning.page:23
|
|
|
15.
|
|
|
Define API stability guarantees for your project. (<link xref="#stability"/>)
|
|
|
(itstool) path: item/p
|
|
|
|
|
(no translation yet)
|
|
|
|
Located in
C/api-stability.page:26
|
|
|
16.
|
|
|
Ensure version numbers are changed as appropriate when API changes. (<link xref="#versioning"/>)
|
|
|
(itstool) path: item/p
|
|
|
|
|
(no translation yet)
|
|
|
|
Located in
C/api-stability.page:30
|
|
|
17.
|
|
|
API and ABI
|
|
|
(itstool) path: section/title
|
|
|
|
|
(no translation yet)
|
|
|
|
Located in
C/api-stability.page:38
|
|
|
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.
|
|
|
(itstool) path: section/p
|
|
|
|
|
(no translation yet)
|
|
|
|
Located in
C/api-stability.page:40
|
|
|
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.
|
|
|
(itstool) path: section/p
|
|
|
|
|
(no translation yet)
|
|
|
|
Located in
C/api-stability.page:54
|
|
|
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.
|
|
|
(itstool) path: section/p
|
|
|
|
|
(no translation yet)
|
|
|
|
Located in
C/api-stability.page:59
|
