[doc]: https://github.com/golang/go/wiki/Modules#releasing-modules-v2-or-higher
Per this Go modules [doc] a repo or branch that's
already tagged v2 or higher should increment the major
version (e.g. go to v3) when releasing their first Go
module-based packages.
At the moment, the kustomize repo has these top level
packages in the sigs.k8s.io/kustomize module:
- `cmd` - holds main program for kustomize
Conceivably someone can depend on this
package for integration tests.
- `internal` - intentionally unreleased subpackages
- `k8sdeps` - an adapter wrapping k8s dependencies
This exists only for use in pre-Go-modules kustomize-into-kubectl
integration and won't live much longer (as everything involved is
switching to Go modules).
- `pkg` - kustomize packages for export
This should shrink in later versions, since
the surface area is too large, containing
sub-packages that should be in 'internal'.
- `plugin` - holds main programs for plugins
This PR changes the top level go.mod file from
```
module sigs.k8s.io/kustomize
```
to
```
module sigs.k8s.io/kustomize/v3
```
and adjusts all import statements to
reflect the change.
Modify all `build` tests to use the raw,
non-sorted output of build. This makes every test
provide coverage for how kustomize re-orders (or
doesn't reorder) resources during processing.
Going forward, the ordering of resources in
_expected_ output should match the depth-first
ordering specified in the `resources:` field used
in the test's kustomization file.
The only exception to this rule would be tests
that actually confirmed some other output
ordering, e.g. the test of the
`LegacyOrderTransformer` plugin.
Fixes#756
Related #821
The previous implementation had a bug and poorly handled
types that should not have a `spec: replica:` field.
Documentation is updated to reflect the change in behavior,
and better highlights the cases where a patch should be
used instead of this shorthand.
