kubernetes-sigs/kustomize
1
0
Fork 0
mirror of https://github.com/kubernetes-sigs/kustomize.git synced 2026-05-17 18:25:26 +00:00
Code Issues Packages Projects Releases 1 Wiki Activity

Fix markdownlint warnings

Browse Source
This commit is contained in:
Yujun Zhang
2019-03-09 17:02:39 +08:00
parent 0f571b9120
commit 3d0e29075d
1 changed files with 24 additions and 25 deletions
Download Patch File Download Diff File Expand all files Collapse all files

49
docs/versioningPolicy.md
View File

@@ -19,14 +19,14 @@ number are bumped per semver.
At the time of writing (circa release of v2.0.0):
- A [kustomization] file is just a YAML file that
can be successfully parsed into a particular Go
struct defined in the `kustomize` binary.
- A [kustomization] file is just a YAML file that
can be successfully parsed into a particular Go
struct defined in the `kustomize` binary.
- This struct does not have a version number,
which is the same as saying that its version
number matches the program's version number,
since it's compiled in.
- This struct does not have a version number,
which is the same as saying that its version
number matches the program's version number,
since it's compiled in.
### Field Change Policy
@@ -92,16 +92,16 @@ process for making [changes].
The presence of an `apiVersion` field in a k8s
native type signals:
- its reliability level (alpha vs beta vs
generally available),
- its reliability level (alpha vs beta vs
generally available),
- the existence of code to provide default values
to fields not present in a serialization,
- the existence of code to provide both forward
and backward conversion between different
versions of types.
- the existence of code to provide default values
to fields not present in a serialization,
- the existence of code to provide both forward
and backward conversion between different
versions of types.
The k8s API promises a lossless _conversion_
between versions over a specific range. This
means that a recent client can write an object
@@ -124,13 +124,13 @@ defaulting and conversions).
The critical difference between k8s API versioning
and kustomization file versioning is
- A k8s API server is able to go _forward_ and
_backward_ in versioning, to work with older
clients, over [some range].
- A k8s API server is able to go _forward_ and
_backward_ in versioning, to work with older
clients, over [some range].
- The `kustomize edit fix` command only moves
_forward_ within a _major_ program
version.
- The `kustomize edit fix` command only moves
_forward_ within a _major_ program
version.
At the time of writing, the YAML in a
kustomization file does not represent a [k8s API]
@@ -160,7 +160,7 @@ a kustomization file: [`kind`] and [`apiVersion`].
If either field is present, they both must be, and
they must have the following values:
```
``` yaml
kind: Kustomization
apiVersion: kustomize.config.k8s.io/v1beta1
```
@@ -171,7 +171,7 @@ domain-squatting behavior for some future API. A
kustomize user gains nothing from adding these
fields to a kustomization file.
### Why not require `kind` and `apiVersion`?
### Why not require `kind` and `apiVersion`
#### Ease of use and setting proper expectations
@@ -203,7 +203,6 @@ locked into `/v1beta1` or `/v1` and the `kind`
and `apiVersion` fields can be required from that
moment forward.
[field change policy]: #field-change-policy
[some range]: https://kubernetes.io/docs/reference/using-api/deprecation-policy
[proposal]: https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/customresources-versioning.md