whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Moving forward from beta blog post: clarify 9 month window

Browse Source 
The 9 month window can be more explicitly translated to "three
releases", which may not always nine month (like for v1.19.0). This
should avoid confusion when users try to find out which release should
be targeted for the graduation to stable.

Signed-off-by: Sascha Grunert <sgrunert@suse.com>
This commit is contained in:
Sascha Grunert
2020-09-02 12:56:55 +02:00
parent dcb611d8d5
commit 073504b3e6
1 changed files with 5 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/en/blog/_posts/2020-08-21-Moving-Forward-From-Beta/index.md
+5 -4
View File
@@ -61,7 +61,7 @@ mind.
## Avoiding permanent beta
For Kubernetes REST APIs, when a new feature's API reaches beta, that starts a countdown.
The beta-quality API now has **nine calendar months** to either:
The beta-quality API now has **three releases** (about nine calendar months) to either:
- reach GA, and deprecate the beta, or
- have a new beta version (_and deprecate the previous beta_).
@@ -69,9 +69,10 @@ To be clear, at this point **only REST APIs are affected**. For example, _APILis
a beta feature but isn't itself a REST API. Right now there are no plans to automatically
deprecate _APIListChunking_ nor any other features that aren't REST APIs.
If a REST API reaches the end of that 9 month countdown, then the next Kubernetes release
will deprecate that API version. There's no option for the REST API to stay at the same
beta version beyond the first Kubernetes release to come out after the 9 month window.
If a beta API has not graduated to GA after three Kubernetes releases, then the
next Kubernetes release will deprecate that API version. There's no option for
the REST API to stay at the same beta version beyond the first Kubernetes
release to come out after the release window.
### What this means for you