michaelh/zephyr
1
0
Fork 0
Code Releases Activity

docs: api_lifecycle: Use a better release as example for deprecation

Browse source 
1.16 was not meant to be a release, and 1.14 was long ago.
Let's use as example something much more recent.

Signed-off-by: Alberto Escolar Piedras <alberto.escolar.piedras@nordicsemi.no>
This commit is contained in:
Alberto Escolar Piedras 2024-08-14 12:27:53 +02:00 • committed by Alberto Escolar
commit e60ad59e9f
1 changed files with 3 additions and 2 deletions
Download patch file Download diff file Expand all files Collapse all files

5
doc/develop/api/api_lifecycle.rst
View file

@ -219,8 +219,8 @@ The following are the requirements for deprecating an existing API:
- Deprecation Time (stable APIs): 2 Releases
The API needs to be marked as deprecated in at least two full releases.
For example, if an API was first deprecated in release 1.14,
it will be ready to be removed in 1.16 at the earliest.
For example, if an API was first deprecated in release 4.0,
it will be ready to be removed in 4.2 at the earliest.
There may be special circumstances, determined by the Architecture working group,
where an API is deprecated sooner.
- What is required when deprecating:
@ -239,6 +239,7 @@ The following are the requirements for deprecating an existing API:
- Add an entry in the corresponding release
`GitHub issue <https://github.com/zephyrproject-rtos/zephyr/labels/deprecation_tracker>`_
tracking removal of deprecated APIs.
In this example in the one corresponding to the 4.2 release.
During the deprecation waiting period, the API will be in the ``deprecated``
state. The Zephyr maintainers will track usage of deprecated APIs on