More release note tweaks.

docs/v_2.1.0.md

@@ -150,78 +150,83 @@ For more information see the
 
 ## Field changes / deprecations
 
-* Generalized `resources` field.
+###  `resources` expanded, `bases` deprecated
 
-  The `resources` field has been generalized; it
+The `resources` field has been generalized; it now
-  now accepts what formerly could only be
+accepts what formerly could only be specified in
-  specified in the `bases` field.
+the `bases` field.
 
-  This change was made so that the `resources`,
+This change was made to allow users fine control
-  `generators` and `transformers` fields all
+over resource processing order.  With a distinct
-  accept the same argument format.
+`bases` field, bases had to be loaded separately
+from resources as a group.  Now, base loading may
+be interleaved as desired with the loading of
+resource files from the current
+directory. [Resource ordering](#resource-ordering)
+had to be respected before this feature could be
+introduced.
 
-  > Each field's argument is a _string list_,
+The `bases` field is now deprecated, and will be
-  > where each entry is either a _resource_ (a
+deleted in some future major release.  Manage the
-  > relative path to a YAML file) or a
+deprecation simply moving the arguments of the
-  > [_kustomization_] (a relative path or URL
+`bases` field to the `resources` field in the
-  > pointing to a directory with a kustomization
+desired order, e.g.
-  > file).  A kustomization directory used in this
-  > context is called a [_base_].
 
-  The `bases` field still works, but is
+> ```
-  deprecated.  Deal with this by simply moving the
+> resources:
-  arguments of the `bases` field to the
+> - someResouceFile.yaml
-  `resources` field in the desired order, e.g.
+> - someOtherResourceFile.yaml
+> bases:
+> - ../../someBaseDir
+> ```
 
-  > ```
+could become
-  > resources:
-  > - someResouceFile.yaml
-  > - someOtherResourceFile.yaml
-  > bases:
-  > - ../../someBaseDir
-  > ```
 
-  could become
+> ```
+> resources:
+> - someResouceFile.yaml
+> - ../../someBaseDir
+> - someOtherResourceFile.yaml
+> ```
 
-  > ```
+The `kustomized edit fix` command will do this for
-  > resources:
+you, though it will always put the bases at the
-  > - someResouceFile.yaml
+end.
-  > - ../../someBaseDir
-  > - someOtherResourceFile.yaml
-  > ```
 
-  The depth-first traversal order of items in the
+As an aside, the `resources`, `generators` and
-  `resources:` field is respected by
+`transformers` fields now all accept the same
-  kustomize, allowing one to, say, process
+argument format.
-  `someBaseDir` between the two resource files.
-  See this discussion of
-  [the `build --reorder` flag](#resource-ordering).
 
-  The _base_ as a concept is as important as ever,
+> Each field's argument is a _string list_,
-  it's just that two new fields (`generators` and
+> where each entry is either a _resource_ (a
-  `tranformers`) and one existing field
+> relative path to a YAML file) or a
-  (`resources`) now accept arguments that were
+> [_kustomization_] (a path or URL
-  once accepted only by `bases`.
+> pointing to a directory with a kustomization
+> file).  A kustomization directory used in this
+> context is called a [_base_].
 
-  The fact that the `generators` and
+The fact that the `generators` and `transformers`
-  `transformers` field accept [bases]
+field accept [bases] and the fact that generator
-  (i.e. kustomization directories) and the fact
+and transformer configuration objects are just
-  that generator and transformer configuration
+normal k8s resources means that one can generate
-  objects are normal k8s resources means that one
+or transform a generator or a transformer (see
-  can generate or transform a generator or a
+[TestTransformerTransformers]).
-  transformer (see [TestTransformerTransformers]).
 
 [TestTransformerTransformers]: ../pkg/target/transformerplugin_test.go
 
-* Consistent `envs` field for Secret and
+### `replicas` field
-  ConfigMap generators.
 
-  An `envs` sub-field has been added to both
+The common task of patching a deployment to edit
-  `configMapGenerator` and `secretGenerator`,
+the number of replicas is now made easier
-  replacing the now deprecated (and singular)
+with the new [replicas](fields.md#replicas) field. 
-  `env` field.  The new field accepts lists, just
-  like its sibling fields `files` and `literals`.
 
-Optionally `kustomize edit fix` to edit your
+### `envs` field
-kustomization file (e.g. merge singular `env`
+
-field into a plural field).
+An `envs` sub-field has been added to both
+`configMapGenerator` and `secretGenerator`,
+replacing the now deprecated (and singular)
+`env` field.  The new field accepts lists, just
+like its sibling fields `files` and `literals`.
+
+Optionally use `kustomize edit fix` to merge
+singular `env` field into a plural field.