Add API versioning and deprecation policy #14975
Conversation
varbanv
requested review from
klaudiagrz,
mmitoraj,
majakurcius,
NHingerl and
grego952
as code owners
|
|
varbanv
added
the
do-not-merge/work-in-progress
kyma-bot
added
the
size/M
✅ 🥰 Documentation preview ready! 🥰
To edit notification comments on pull requests, go to your Netlify site settings. |
varbanv
changed the title
kyma-bot
removed
the
do-not-merge/work-in-progress
varbanv
added
the
do-not-merge/work-in-progress
|
/retest |
Co-authored-by: Piotr Bochyński <p.bochynski@gmail.com>
There was a problem hiding this comment.
Majority of the content is copied from https://kubernetes.io/docs/reference/using-api/deprecation-policy
Please make it a quote, provide the source (or maybe just link it instead).
Added links to the official Kubernetes documentation that provided the source for the policy.
varbanv
removed
the
do-not-merge/work-in-progress
|
/retest |
|
|
||
| ### REST resources (aka API objects) | ||
|
|
||
| Consider a hypothetical REST resource named Widget, which was present in API v1 in the above timeline, and which needs to be deprecated. We document and announce the deprecation in sync with release X+1. The Widget resource still exists in API version v1 (deprecated) but not in v2alpha1. The Widget resource continues to exist and function in releases up to and including X+8. Only in release X+9, when API v1 has aged out, does the Widget resource cease to exist, and the behavior get removed. |
There was a problem hiding this comment.
Correct me if I'm wrong, but I think the numbers in the following sentences need to be changed as the period of supporting beta API versions has been changed from 9 to 6 months.
"The Widget resource continues to exist and function in releases up to and including X+8. The Widget resource ceases to exist, and the behavior gets removed in release X+9,..."
|
|
||
| ### Fields of REST resources | ||
|
|
||
| As with whole REST resources, an individual field which was present in API v1 must exist and function until API v1 is removed. Unlike whole resources, the v2 APIs may choose a different representation for the field, as long as it can be round-tripped. For example a v1 field named "magnitude" which was deprecated might be named "deprecatedMagnitude" in API v2. When v1 is eventually removed, the deprecated field can be removed from v2. |
There was a problem hiding this comment.
The phrase "whole REST resources" is used a few times and I'd like to clarify if the meaning is all of REST resources meaning each of them, or each of them as a whole - shall we say - unit.
There was a problem hiding this comment.
It should be the second - so you can deprecate the whole REST resource, or just one or more fields.
Co-authored-by: Iwona Langer <iwona.langer@sap.com>
|
@varbanv: The following tests failed, say
Full PR test history. Your PR dashboard. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here. |
Description
Changes proposed in this pull request:
Related issue(s)
#14737