[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.
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.
If path segments end with the special marker `[]` in transformer configs, this
indicates that the respective path segment is supposed to be an array. That
information may be used to suppress the meaningless creation of non-existent
paths that should be arrays, not objects.
Projected volumes can include values sourced from secrets that might be
managed by kustomize. To support this use case this patch updates the
name reference transformer configuration to include a field spec for
projected secrets.
Fixes#366
To reproduce #366, add
```
bases:
- .
```
to `examples/helloWorld/kustomization.yaml`, attempt to build it, and enjoy the stack overflow.
This PR fixes this by adding history to file loaders,
allowing one to avoid cycles in overlay->base
relationships. To make entry points clearer, this PR
exposes only two public ways to make a fresh
(no-history) loader
* rooted at `/`
* rooted at the process's current working directory.
When making a new loader from an existing loader,
retaining history along an overlay trace, the only
allowed use is to go deeper into a file hierarchy, or
go up and over to a never before visited sibling. This
fix can probably be defeated by devious symbolic links.
