Fix markdownlint warnings

docs/versioningPolicy.md

@@ -19,11 +19,11 @@ 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
+- 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,
+- 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.
@@ -92,13 +92,13 @@ process for making [changes].
 The presence of an `apiVersion` field in a k8s
 native type signals:
 
- - its reliability level (alpha vs beta vs
+- its reliability level (alpha vs beta vs
   generally available),
 
- - the existence of code to provide default values
+- the existence of code to provide default values
   to fields not present in a serialization,
   
- - the existence of code to provide both forward
+- the existence of code to provide both forward
   and backward conversion between different
   versions of types.
 
@@ -124,11 +124,11 @@ 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
+- 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
+- The `kustomize edit fix` command only moves
   _forward_ within a _major_ program
   version.
 
@@ -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