Lines Matching full:api
3 API Lifecycle
7 given API will not change in future releases. At the same time, developers
15 :alt: API Life Cycle
18 API Life Cycle
35 - Documentation of the API (usage)
38 - The API introduction should be accompanied by at least one implementation
39 of said API (in the case of peripheral APIs, this corresponds to one driver)
40 - At least one sample using the new API (may only build on one single board)
42 When introducing a new and experimental API, mark the API version in the headers
43 where the API is defined. An experimental API shall have a version where the minor
49 When introducing an API (public header file with documentation) for a new
50 peripheral or driver subsystem, review of the API is enforced and is driven by
53 The API shall be promoted to ``unstable`` when it has at least two
61 The API is in the process of settling, but has not yet had sufficient real-world
62 testing to be considered stable. The API is considered generic in nature and can
65 When the API changes status to unstable API, mark the API version in the headers
66 where the API is defined. Unstable APIs shall have a version where the minor
76 The API shall be promoted from ``experimental`` to ``unstable`` when it has at
83 promote an API from ``experimental`` to ``unstable``.
90 The API has proven satisfactory, but cleanup in the underlying code may cause
93 An API can be declared ``stable`` after fulfilling the following requirements:
95 - Test cases for the new API with 100% coverage
98 - The API has been in-use and was available in at least 2 development releases
102 In order to declare an API ``stable``, the following steps need to be followed:
106 #. An email must be sent to the ``devel`` mailing list announcing the API
113 When the API changes status to stable API, mark the API version in the headers
114 where the API is defined. Stable APIs shall have a version where the major
119 Introducing breaking API changes
122 A stable API, as described above, strives to remain backwards-compatible through
125 maintenance of the API and its implementation(s).
127 A breaking API change is defined as one that forces users to modify their
130 itself) is not considered a breaking API change.
141 Title: RFC: Breaking API Change: <subsystem>
145 - Brief description of the API change
151 - Impact to users of the API, including the steps required
152 to adapt out-of-tree users of the API to the change
156 #. The RFC issue must be labeled with the GitHub ``Breaking API Change`` label
175 - The actual changes to the API
177 - Changes to the API header file
178 - Changes to the API implementation(s)
179 - Changes to the relevant API documentation
182 - The changes required to adapt in-tree users of the API to the change.
185 - An entry in the "API Changes" section of the release notes for the next
187 - The labels ``API``, ``Breaking API Change`` and ``Release Notes``, as well as
200 The API version shall be changed to signal backward incompatible changes. This
207 Breaking API changes will be listed and described in the migration guide.
215 Deprecation and removal of APIs will be announced in the "API Changes"
218 The following are the requirements for deprecating an existing API:
221 The API needs to be marked as deprecated in at least two full releases.
222 For example, if an API was first deprecated in release 4.0,
225 where an API is deprecated sooner.
234 - Include the deprecation in the "API Changes" of the release notes for the
236 - Code using the deprecated API needs to be modified to remove usage of said
237 API
244 During the deprecation waiting period, the API will be in the ``deprecated``
249 - API documentation will inform users that the API is deprecated.
250 - Attempts to use a deprecated API at build time will log a warning to the
257 In this phase, the API is removed.
260 The Zephyr maintainers will decide when to actually remove the API: this
262 deprecated API, and on how urgently the API needs to be removed.
264 If it's OK to remove the API, it will be removed. The maintainers will remove
268 If it's not OK to remove the API, the maintainers will continue to support
269 migration and update the roadmap with the aim to remove the API in the next