Clarify that beta annotations can not be removed (#8666)

* Clarify that beta annotations can not be removed

Removing annotations caused a major outage with nodes that lagged the
master.  We used annotations as would-be fields, though we don't any
more.  Now we just add fields.  That makes them part of the API version.
These annotations are effectively part of the API version, too.

It stinks because I love to delete code, but I think it's just part of
the debt-accrual process and yet another reason we need to be judicious
in adding fields.

* Change 6 month deprecations to 9 months

This covers maximum version skew.  For example a master might be at
1.10, while nodes are at 1.8.  We must not break compat within that
window.
pull/8811/head
Tim Hockin 2018-05-29 15:54:52 -07:00 committed by k8s-ci-robot
parent 56bbcf5c8f
commit 42deca26af
1 changed files with 23 additions and 19 deletions

View File

@ -37,6 +37,8 @@ includes:
* REST resources (aka API objects)
* Fields of REST resources
* Annotations on REST resources, including "beta" annotations but not
including "alpha" annotations.
* Enumerated or constant values
* Component config structures
@ -75,15 +77,17 @@ versions. Beta API versions *may not* replace GA API versions.
versions must be supported after their announced deprecation for a duration of
no less than:**
* **GA: 1 year or 2 releases (whichever is longer)**
* **Beta: 6 months or 2 releases (whichever is longer)**
* **GA: 12 months or 3 releases (whichever is longer)**
* **Beta: 9 months or 3 releases (whichever is longer)**
* **Alpha: 0 releases**
This covers the maximum supported version skew of 2 releases.
NOTE: Until [#52185](https://github.com/kubernetes/kubernetes/issues/52185) is
resolved, no API versions may be removed.
**Rule #4b: The "preferred" API version and the "storage version" for a given
group may not advance util after a release has been made that supports both the
group may not advance until after a release has been made that supports both the
new version and the previous version**
Users must be able to upgrade to a new release of Kubernetes and then roll back
@ -151,11 +155,10 @@ API versions are supported in a series of subsequent releases.
</tr>
<tr>
<td>X+5</td>
<td>v1, v1beta2 (deprecated)</td>
<td>v1, v1beta1 (deprecated), v1beta2 (deprecated)</td>
<td>v1beta2</td>
<td>
<ul>
<li>v1beta1 is removed, "action required" relnote</li>
<li>v1beta2 is deprecated, "action required" relnote</li>
</ul>
</td>
@ -166,12 +169,19 @@ API versions are supported in a series of subsequent releases.
<td>v1</td>
<td>
<ul>
<li>v1beta1 is removed, "action required" relnote</li>
</ul>
</td>
</tr>
<tr>
<td>X+7</td>
<td>v1, v1beta2 (deprecated)</td>
<td>v1</td>
<td></td>
</tr>
<tr>
<td>X+8</td>
<td>v2alpha1, v1</td>
<td>v1</td>
<td>
<ul>
@ -179,12 +189,6 @@ API versions are supported in a series of subsequent releases.
</ul>
</td>
</tr>
<tr>
<td>X+8</td>
<td>v2alpha1, v1</td>
<td>v1</td>
<td></td>
</tr>
<tr>
<td>X+9</td>
<td>v2alpha2, v1</td>
@ -228,6 +232,12 @@ API versions are supported in a series of subsequent releases.
</tr>
<tr>
<td>X+13</td>
<td>v2, v2beta1 (deprecated), v2beta2 (deprecated), v1 (deprecated)</td>
<td>v2</td>
<td></td>
</tr>
<tr>
<td>X+14</td>
<td>v2, v2beta2 (deprecated), v1 (deprecated)</td>
<td>v2</td>
<td>
@ -237,7 +247,7 @@ API versions are supported in a series of subsequent releases.
</td>
</tr>
<tr>
<td>X+14</td>
<td>X+15</td>
<td>v2, v1 (deprecated)</td>
<td>v2</td>
<td>
@ -246,12 +256,6 @@ API versions are supported in a series of subsequent releases.
</ul>
</td>
</tr>
<tr>
<td>X+15</td>
<td>v2, v1 (deprecated)</td>
<td>v2</td>
<td></td>
</tr>
<tr>
<td>X+16</td>
<td>v2, v1 (deprecated)</td>
@ -322,7 +326,7 @@ follows:
**Rule #5a: CLI elements of user-facing components (e.g. kubectl) must function
after their announced deprecation for no less than:**
* **GA: 1 year or 2 releases (whichever is longer)**
* **GA: 12 months or 2 releases (whichever is longer)**
* **Beta: 3 months or 1 release (whichever is longer)**
* **Alpha: 0 releases**