github
/
k3s
mirror of https://github.com/k3s-io/k3s
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

Merge pull request #66302 from wking/apimachinery-runtime-doc-list 

Automatic merge from submit-queue. If you want to cherry-pick this change to another branch, please follow the instructions <a href="https://github.com/kubernetes/community/blob/master/contributors/devel/cherry-picks.md">here</a>.

apimachinery/pkg/runtime/doc: Split list into paragraphs

[Godoc uses go/doc][1] to convert comments to HTML, and go/doc [has no markup for lists][2].  With the previous comment, the lack of paragraph-splitting lines between the list entries was leading to entries 0, 1, etc. being formatted as a single paragraph.  And the hanging indents for entry 3, etc. were leading to formatting within `<pre>` blocks:

```console
$ curl -s https://godoc.org/k8s.io/apimachinery/pkg/runtime | grep -B1 -A7 'Your API objects'
<p>
0. Your API objects have a common metadata struct member, TypeMeta.
1. Your code refers to an internal set of API objects.
2. In a separate package, you have an external set of API objects.
3. The external set is considered to be versioned, and no breaking
</p>
<pre>changes are ever made to it (fields may be added but not changed
or removed).
</pre>
```

```release-note
NONE
```

[1]: https://godoc.org/golang.org/x/tools/cmd/godoc
[2]: https://golang.org/pkg/go/doc/#ToHTML
pull/8/head
Kubernetes Submit Queue 2018-07-17 23:18:33 -07:00 committed by GitHub
parent f250d676f9 7a546ef223
commit a00e3748d4
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 14 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

7
staging/src/k8s.io/apimachinery/pkg/runtime/doc.go
View File

@ -18,18 +18,25 @@ limitations under the License.
// that follow the kubernetes API object conventions, which are:
//
// 0. Your API objects have a common metadata struct member, TypeMeta.
//
// 1. Your code refers to an internal set of API objects.
//
// 2. In a separate package, you have an external set of API objects.
//
// 3. The external set is considered to be versioned, and no breaking
// changes are ever made to it (fields may be added but not changed
// or removed).
//
// 4. As your api evolves, you'll make an additional versioned package
// with every major change.
//
// 5. Versioned packages have conversion functions which convert to
// and from the internal version.
//
// 6. You'll continue to support older versions according to your
// deprecation policy, and you can easily provide a program/library
// to update old versions into new versions because of 5.
//
// 7. All of your serializations and deserializations are handled in a
// centralized place.
//