Lines Matching refs:be
8 maintaining and extending Zephyr's APIs need to be able to introduce
20 An up-to-date table of all APIs and their maturity level can be found in the
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
38 - The API introduction should be accompanied by at least one implementation
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
63 be used on different hardware platforms.
71 Changes will not be announced.
76 The API shall be promoted from ``experimental`` to ``unstable`` when it has at
91 minor changes. Backwards-compatibility will be maintained if reasonable.
93 An API can be declared ``stable`` after fulfilling the following requirements:
96 - Complete documentation in code. All public interfaces shall be documented
102 In order to declare an API ``stable``, the following steps need to be followed:
104 #. A Pull Request must be opened that changes the corresponding entry in the
106 #. An email must be sent to the ``devel`` mailing list announcing the API
108 #. The Pull Request must be submitted for discussion in the next
110 will be merged
133 promise of backwards compatibility, the following steps must be followed whenever
136 #. An :ref:`RFC issue <rfcs>` must be opened on GitHub with the following
156 #. The RFC issue must be labeled with the GitHub ``Breaking API Change`` label
157 #. The RFC issue must be submitted for discussion in the next `Zephyr
159 #. An email must be sent to the ``devel`` mailing list with a subject identical
162 The RFC will then receive feedback through issue comments and will also be
166 Finally, and if not done as part of the first step, a Pull Request must be
170 proceed with confidence that it will be accepted.
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
207 Breaking API changes will be listed and described in the migration guide.
214 Unstable APIs can be removed without deprecation at any time.
215 Deprecation and removal of APIs will be announced in the "API Changes"
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.
224 There may be special circumstances, determined by the Architecture working group,
228 - Mark as deprecated. This can be done by using the compiler itself
236 - Code using the deprecated API needs to be modified to remove usage of said
238 - The change needs to be atomic and bisectable
244 During the deprecation waiting period, the API will be in the ``deprecated``
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