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

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 <[email protected]>
argentum-systems · Aug 15, 2024 · e60ad59 · e60ad59
1 parent 3f48089
commit e60ad59
Showing 1 changed file with 3 additions and 2 deletions.
diff --git a/doc/develop/api/api_lifecycle.rst b/doc/develop/api/api_lifecycle.rst
@@ -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