[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.
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.
