Lines Matching full:to
6 Developers using Zephyr's APIs need to know how long they can trust that a
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
31 to the community via the `Developer mailing list <https://lists.zephyrproject.org/g/devel>`_.
33 The following requirements apply to all new APIs:
36 explaining its design and assumptions, how it is to be used, current
39 of said API (in the case of peripheral APIs, this corresponds to one driver)
44 version is up to one (0.1.z). (see :ref:`api_overview`)
53 The API shall be promoted to ``unstable`` when it has at least two
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
76 The API shall be promoted from ``experimental`` to ``unstable`` when it has at
82 For hardware agnostic APIs, multiple applications using it are required to
83 promote an API from ``experimental`` to ``unstable``.
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
122 A stable API, as described above, strives to remain backwards-compatible through
127 A breaking API change is defined as one that forces users to modify their
128 existing code in order to maintain the current behavior of their application.
132 In order to restrict and control the introduction of a change that breaks the
134 such a change is considered necessary in order to accept it in the project:
151 - Impact to users of the API, including the steps required
152 to adapt out-of-tree users of the API to the change
154 Instead of a written description of the changes, the RFC issue may link to a
159 #. An email must be sent to the ``devel`` mailing list with a subject identical
160 to the RFC issue title and that links to the RFC issue
164 community at large will have a chance to discuss it in detail.
167 opened on GitHub. It is left to the person proposing the change to decide
168 whether to introduce both the RFC and the Pull Request at the same time or to
174 - A link to the RFC issue
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
180 - Changes to Device Tree source and bindings
182 - The changes required to adapt in-tree users of the API to the change.
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
200 The API version shall be changed to signal backward incompatible changes. This
202 include minor and patch level changes. Patch and minor versions MUST be reset to
221 The API needs to be marked as deprecated in at least two full releases.
223 it will be ready to be removed in 4.2 at the earliest.
232 back to their previous form
236 - Code using the deprecated API needs to be modified to remove usage of said
238 - The change needs to be atomic and bisectable
242 In this example in the one corresponding to the 4.2 release.
247 will continue to provide warnings:
250 - Attempts to use a deprecated API at build time will log a warning to the
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