diff options
| author | Slava Semushin <vsemushi@redhat.com> | 2017-10-06 19:22:24 +0200 |
|---|---|---|
| committer | Slava Semushin <vsemushi@redhat.com> | 2017-10-06 19:22:24 +0200 |
| commit | 333cf0d960950f2ae87417d46c23e853e63d952d (patch) | |
| tree | c0b2cec2ad06dc33c26e99e2475ce5e2e9036c38 | |
| parent | ff82a64245cc88cd1b8828b8e7cd001008770415 (diff) | |
contributors/devel/api_changes.md: don't suggest to create API in extensions group as it's been deprecated.
| -rw-r--r-- | contributors/devel/api_changes.md | 7 |
1 files changed, 1 insertions, 6 deletions
diff --git a/contributors/devel/api_changes.md b/contributors/devel/api_changes.md index 1e689a43..3155490c 100644 --- a/contributors/devel/api_changes.md +++ b/contributors/devel/api_changes.md @@ -37,8 +37,7 @@ found at [API Conventions](api-conventions.md). Before attempting a change to the API, you should familiarize yourself with a number of existing API types and with the [API conventions](api-conventions.md). If creating a new API type/resource, we also recommend that you first send a PR -containing just a proposal for the new API types, and that you initially target -the extensions API (pkg/apis/extensions). +containing just a proposal for the new API types. The Kubernetes API has two major components - the internal structures and the versioned APIs. The versioned APIs are intended to be stable, while the @@ -322,15 +321,11 @@ If you found that your change accidentally broke clients, it should be reverted. In short, the expected API evolution is as follows: -* `extensions/v1alpha1` -> * `newapigroup/v1alpha1` -> ... -> `newapigroup/v1alphaN` -> * `newapigroup/v1beta1` -> ... -> `newapigroup/v1betaN` -> * `newapigroup/v1` -> * `newapigroup/v2alpha1` -> ... -While in extensions we have no obligation to move forward with the API at all -and may delete or break it at any time. - While in alpha we expect to move forward with it, but may break it. Once in beta we will preserve forward compatibility, but may introduce new |