From bd4e1aafe89e9a5260b9fe64d27ee756897fee31 Mon Sep 17 00:00:00 2001 From: Balaji Veeramani Date: Tue, 28 Jul 2026 13:40:03 -0700 Subject: [PATCH 1/2] Initial commit Signed-off-by: Balaji Veeramani --- doc/source/ray-contribute/api-policy.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/doc/source/ray-contribute/api-policy.md b/doc/source/ray-contribute/api-policy.md index e9a13cb85c9f..310e3c40062f 100644 --- a/doc/source/ray-contribute/api-policy.md +++ b/doc/source/ray-contribute/api-policy.md @@ -69,13 +69,13 @@ Users have high expectations for certain exposure levels, so we need to be cauti - No - Yes * - Can this API be demoted to a lower level? If so then how? - - Can be demoted to Deprecated only. The API should emit warning messages and a deadline for deprecations in **six months (or +25 Ray minor versions)**. - - Can be demoted to Deprecated only. The API should emit warning messages and a deadline for deprecations in **three months (or +12 Ray minor versions)**. + - Can be demoted to Deprecated only. The API should emit warning messages and a deadline for deprecations in **six months or +25 Ray minor versions, whichever comes first**. + - Can be demoted to Deprecated only. The API should emit warning messages and a deadline for deprecations in **three months or +12 Ray minor versions, whichever comes first**. - Users must allow for and expect breaking changes in alpha components, and must have no expectations of stability. - Yes - No annotations mean it is a developer API by default * - Can you remove or change this API's parameters? - - Yes. The API should emit warning messages and you must set a deadline for the end-of-life of the original version that is **six months or +25 Ray minor versions**. During the transition period, you must support both the new and old parameters. + - Yes. The API should emit warning messages and you must set a deadline for the end-of-life of the original version that is **six months or +25 Ray minor versions, whichever comes first**. During the transition period, you must support both the new and old parameters. - Yes. The API should emit warning messages and you must set a deadline for the change in **three months or +12 Ray minor versions**. During the transition period, you must support both the new and old parameters. - Users must allow for and expect breaking changes in alpha components, and must have no expectations of stability. - No From 3869f70abe7188bae8deccfc045cbbf7001951c0 Mon Sep 17 00:00:00 2001 From: Balaji Veeramani Date: Wed, 29 Jul 2026 14:07:53 -0700 Subject: [PATCH 2/2] Address review comment Signed-off-by: Balaji Veeramani --- doc/source/ray-contribute/api-policy.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/source/ray-contribute/api-policy.md b/doc/source/ray-contribute/api-policy.md index 310e3c40062f..ee4da14689ca 100644 --- a/doc/source/ray-contribute/api-policy.md +++ b/doc/source/ray-contribute/api-policy.md @@ -76,7 +76,7 @@ Users have high expectations for certain exposure levels, so we need to be cauti - No annotations mean it is a developer API by default * - Can you remove or change this API's parameters? - Yes. The API should emit warning messages and you must set a deadline for the end-of-life of the original version that is **six months or +25 Ray minor versions, whichever comes first**. During the transition period, you must support both the new and old parameters. - - Yes. The API should emit warning messages and you must set a deadline for the change in **three months or +12 Ray minor versions**. During the transition period, you must support both the new and old parameters. + - Yes. The API should emit warning messages and you must set a deadline for the change in **three months or +12 Ray minor versions, whichever comes first**. During the transition period, you must support both the new and old parameters. - Users must allow for and expect breaking changes in alpha components, and must have no expectations of stability. - No - Yes