From e60ad59e9f68b9040d5e4453e71b04289277779d Mon Sep 17 00:00:00 2001 From: Alberto Escolar Piedras Date: Wed, 14 Aug 2024 12:27:53 +0200 Subject: [PATCH] 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 --- doc/develop/api/api_lifecycle.rst | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/doc/develop/api/api_lifecycle.rst b/doc/develop/api/api_lifecycle.rst index 2923451aa02..be7b8b98e5c 100644 --- 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 `_ 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