Merge pull request #30426 from ZJU-SEL/fix-mistakes-in-api-changes

Automatic merge from submit-queue

fix mistakes in api_changes.md

<!--
Checklist for submitting a Pull Request

Please remove this comment block before submitting.

1. Please read our [contributor guidelines](https://github.com/kubernetes/kubernetes/blob/master/CONTRIBUTING.md).
2. See our [developer guide](https://github.com/kubernetes/kubernetes/blob/master/docs/devel/development.md).
3. If you want this PR to automatically close an issue when it is merged,
   add `fixes #<issue number>` or `fixes #<issue number>, fixes #<issue number>`
   to close multiple issues (see: https://github.com/blog/1506-closing-issues-via-pull-requests).
4. Follow the instructions for [labeling and writing a release note for this PR](https://github.com/kubernetes/kubernetes/blob/master/docs/devel/pull-requests.md#release-notes) in the block below.
-->

```release-note
fix mistakes in api_changes.md
```

Signed-off-by: Xianglin Gao <xlgao@zju.edu.cn>

<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.kubernetes.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.kubernetes.io/reviews/kubernetes/kubernetes/30426)
<!-- Reviewable:end -->
This commit is contained in:
Kubernetes Submit Queue 2016-08-12 09:40:20 -07:00 committed by GitHub
commit c0a5c32ead

View File

@ -493,7 +493,7 @@ hack/update-generated-protobuf.sh
The vast majority of objects will not need any consideration when converting
to protobuf, but be aware that if you depend on a Golang type in the standard
library there may be additional work requried, although in practice we typically
library there may be additional work required, although in practice we typically
use our own equivalents for JSON serialization. The `pkg/api/serialization_test.go`
will verify that your protobuf serialization preserves all fields - be sure to
run it several times to ensure there are no incompletely calculated fields.
@ -752,7 +752,7 @@ The latter requires that all objects in the same API group as `Frobber` to be
replicated in the new version, `v6alpha2`. This also requires user to use a new
client which uses the other version. Therefore, this is not a preferred option.
A releated issue is how a cluster manager can roll back from a new version
A related issue is how a cluster manager can roll back from a new version
with a new feature, that is already being used by users. See
https://github.com/kubernetes/kubernetes/issues/4855.