Kustomize v3.0.0

This release is basically v2.1.0, with many post-v2.1.0 bugs fixed (in about 150 commits) and a v3 in Go package paths.

The major version increment to v3 puts a new floor on a stable API for plugin developers (both Go plugin developers and exec plugin developers who happen to use Go).

Why so soon after v2.1.0

We made a mistake - v2.1.0 should have been v3.0.0. Per the Go modules doc (which have improved a great deal recently), a release that’s already tagged v2 or higher should increment the major version when performing their first Go module-based release.

This advice applies to kustomize, since it was already at major version 2 when it began using Go modules to state its own dependencies in v2.1.0.

But the more important reason for v3 is a change to the kustomize versioning policy, forced by the introduction of plugins.

Historically, kustomize’s versioning policy didn’t involve Go modules and addressed only the command line tool’s behavior and the fields in a kustomization file. The underlying packages were an implementation detail, not under semantic versioning, because they weren’t intended for export (and should have all been under internal). Thus although the v2.1.0 CLI is backward compatible with v2.0.3, the underlying package APIs are not.

With Go modules, the go tool must assume that Go packages respect semantic versioning, so it can perform minimal version selection.

With the introduction of alpha plugins, kustomize sub-packages - in particular loader and resmap - become part of an API formally exposed to plugin authors, and so must be semantically versioned. This allows plugins defined in other repositories to clarify that they depend on kustomize v3.0.0, and not see confusing errors arising from incompatibilities between v2.1.0 and v2.0.3. Hence, the jump to v3.

Aside - the set of kustomize packages outside internal is too large, and over time, informed by package use, this API surface must shrink. Such shrinkage will trigger a major version increment.