Lines Matching +full:settling +full:- +full:time
7 given API will not change in future releases. At the same time, developers
16 :figclass: align-center
20 An up-to-date table of all APIs and their maturity level can be found in the
35 - Documentation of the API (usage)
38 - The API introduction should be accompanied by at least one implementation
40 - At least one sample using the new API (may only build on one single board)
61 The API is in the process of settling, but has not yet had sufficient real-world
91 minor changes. Backwards-compatibility will be maintained if reasonable.
95 - Test cases for the new API with 100% coverage
96 - Complete documentation in code. All public interfaces shall be documented
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
100 at any time.
122 A stable API, as described above, strives to remain backwards-compatible through
123 its life-cycle. There are however cases where fulfilling this objective prevents
139 .. code-block:: none
142 Contents: - Problem Description:
143 - Background information on why the change is required
144 - Proposed Change (detailed):
145 - Brief description of the API change
146 - Detailed RFC:
147 - Function call changes
148 - Device Tree changes (source and bindings)
149 - Kconfig option changes
150 - Dependencies:
151 - Impact to users of the API, including the steps required
152 to adapt out-of-tree users of the API to the change
168 whether to introduce both the RFC and the Pull Request at the same time or to
173 - A title that matches the RFC issue
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.
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
189 - The label ``Architecture Review`` if the RFC was not yet discussed and agreed upon in `Zephyr
214 Unstable APIs can be removed without deprecation at any time.
220 - Deprecation Time (stable APIs): 2 Releases
226 - What is required when deprecating:
228 - Mark as deprecated. This can be done by using the compiler itself
233 - Document the deprecation
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
238 - The change needs to be atomic and bisectable
239 - Add an entry in the corresponding release
240 `GitHub issue <https://github.com/zephyrproject-rtos/zephyr/labels/deprecation_tracker>`_
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
266 the release notes, mailing lists, Github issues and pull-requests.
272 …ttps://github.com/zephyrproject-rtos/zephyr/wiki/Zephyr-Committee-and-Working-Group-Meetings#techn…
273 …r Architecture meeting`: https://github.com/zephyrproject-rtos/zephyr/wiki/Architecture-Working-Gr…