Add another detailed plugin example.

docs/v3.0.0.md

@@ -0,0 +1,51 @@
+# kustomize 3.0.0
+
+This release is [v2.1.0](v2.1.0.md), with some
+post v2.1.0 bugs fixed and a `v3` in Go package
+paths.
+
+The `v3` puts plugin developers (both _Go_ plugin
+authors and _exec_ plugin authors who happen to
+use Go) on a solid footing.
+
+
+### Go Module implications
+
+[doc]: https://github.com/golang/go/wiki/Modules#releasing-modules-v2-or-higher
+
+Per the Go modules [doc], 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 switching to Go
+modules.
+
+[versioning policy]: versioningPolicy.md
+
+The other reason for `v3` is that the `go` tool
+assumes Go modules obey semantic versioning, which
+means packages used in v2.1 should have the same
+API as packages in v2.0.
+
+This is not the case in kustomize.  Historically,
+kustomize's [versioning policy] has only addressed
+the command line tool's behavior and the fields in
+a kustomization file.  The underlying packages
+were an implementation detail, avaiable for use at
+the author's risk.
+
+With the introduction of plugins, the packages -
+in particular `loader` and `resmap` - become part
+of an API formally exposed to plugin authors, so
+the API changes must be respected.
+
+Over time, _informed by package use_, the API
+surface should shrink, but such shrinkage will
+require a major version increment.
+
+
+
+
+