Lines Matching refs:and
8 maintaining and extending Zephyr's APIs need to be able to introduce
9 new APIs that aren't yet fully proven, and to potentially retire old APIs when they're
20 An up-to-date table of all APIs and their maturity level can be found in the
29 Experimental APIs denote that a feature was introduced recently, and may change
30 or be removed in future versions. Try it out and provide feedback
36 explaining its design and assumptions, how it is to be used, current
37 implementation limitations, and future potential, if appropriate.
42 When introducing a new and experimental API, mark the API version in the headers
50 peripheral or driver subsystem, review of the API is enforced and is driven by
62 testing to be considered stable. The API is considered generic in nature and can
97 and available in online documentation.
98 - The API has been in-use and was available in at least 2 development releases
99 - Stable APIs can get backward compatible updates, bug fixes and security fixes
125 maintenance of the API and its implementation(s).
132 In order to restrict and control the introduction of a change that breaks the
148 - Device Tree changes (source and bindings)
160 to the RFC issue title and that links to the RFC issue
162 The RFC will then receive feedback through issue comments and will also be
163 discussed in the Zephyr Architecture meeting, where the stakeholders and the
166 Finally, and if not done as part of the first step, a Pull Request must be
168 whether to introduce both the RFC and the Pull Request at the same time or to
180 - Changes to Device Tree source and bindings
187 - The labels ``API``, ``Breaking API Change`` and ``Release Notes``, as well as
189 - The label ``Architecture Review`` if the RFC was not yet discussed and agreed upon in `Zephyr
195 for it to be discussed and ultimately even voted on in the `Zephyr TSC meeting`_.
197 If the Pull Request is merged then an email must be sent to the ``devel`` and
202 include minor and patch level changes. Patch and minor versions MUST be reset to
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"
229 (``__deprecated`` for function declarations and ``__DEPRECATED_MACRO`` for
238 - The change needs to be atomic and bisectable
246 ``docs.zephyrproject.org`` and support developers migrating their code. Zephyr
262 deprecated API, and on how urgently the API needs to be removed.
265 the corresponding documentation, and communicate the removal in the usual ways:
266 the release notes, mailing lists, Github issues and pull-requests.
269 migration and update the roadmap with the aim to remove the API in the next
272 .. _`Zephyr TSC meeting`: https://github.com/zephyrproject-rtos/zephyr/wiki/Zephyr-Committee-and-Wo…