⚠️ (go/v4-alpha) stabilize go/v4 plugin. Plugin go/v4-alpha replaced with go/v4 (#3237)

Author: camilamacedo86

README.md

@@ -127,16 +127,7 @@ supporting Windows are welcome.
 
 ### Apple Silicon
 
-Apple Silicon (`darwin/arm64`) is supported using the `go/v4-alpha` plugin which provides support for this platform. 
-
-```bash
-kubebuilder init --domain my.domain --repo my.domain/guestbook --plugins=go/v4-alpha
-```
-
-**Note**: The `go/v4-alpha` plugin is an unstable version and can have breaking changes in future releases. The previous kustomize 
-version (`v3.Y.Z`) used in the `go/v3` has no available binaries for this 
-platform [kubernetes-sigs/kustomize/issues/4612](https://github.com/kubernetes-sigs/kustomize/issues/4612)
-Because of this, we cannot support this `darwin/arm64` on the stable scaffold done  by default with the Kubebuilder with the `go/v3` plugin.
+Apple Silicon (`darwin/arm64`) support begins with the `go/v4` plugin.
 
 ## Community Meetings
 

cmd/main.go

@@ -25,7 +25,6 @@ import (
 	cfgv2 "sigs.k8s.io/kubebuilder/v3/pkg/config/v2"
 	cfgv3 "sigs.k8s.io/kubebuilder/v3/pkg/config/v3"
 	"sigs.k8s.io/kubebuilder/v3/pkg/machinery"
-	"sigs.k8s.io/kubebuilder/v3/pkg/model/stage"
 	"sigs.k8s.io/kubebuilder/v3/pkg/plugin"
 	kustomizecommonv1 "sigs.k8s.io/kubebuilder/v3/pkg/plugins/common/kustomize/v1"
 	kustomizecommonv2alpha "sigs.k8s.io/kubebuilder/v3/pkg/plugins/common/kustomize/v2"
@@ -46,7 +45,7 @@ func main() {
 		golangv3.Plugin{},
 	)
 	// Bundle plugin which built the golang projects scaffold by Kubebuilder go/v4 with kustomize alpha-v2
-	gov4Bundle, _ := plugin.NewBundle(golang.DefaultNameQualifier, plugin.Version{Number: 4, Stage: stage.Alpha},
+	gov4Bundle, _ := plugin.NewBundle(golang.DefaultNameQualifier, plugin.Version{Number: 4},
 		kustomizecommonv2alpha.Plugin{},
 		golangv4.Plugin{},
 	)

docs/book/src/SUMMARY.md

@@ -68,7 +68,7 @@
       - [Migration Guide](migration/legacy/migration_guide_v2tov3.md)
       - [Migration by updating the files](migration/legacy/manually_migration_guide_v2_v3.md)
   - [From v3.0.0 with plugins](./migration/v3-plugins.md)
-    - [go/v3 vs go/v4-alpha](migration/v3vsv4.md)
+    - [go/v3 vs go/v4](migration/v3vsv4.md)
 
       - [Migration Guide](migration/migration_guide_gov3_to_gov4.md)
       - [Migration by updating the files](migration/manually_migration_guide_gov3_to_gov4.md)
@@ -117,7 +117,7 @@
     - [To scaffold a project](./plugins/to-scaffold-project.md)
       - [go/v2 (Deprecated)](./plugins/go-v2-plugin.md)
       - [go/v3 (Default init scaffold)](./plugins/go-v3-plugin.md)
-      - [go/v4-alpha](./plugins/go-v4-plugin.md)
+      - [go/v4](./plugins/go-v4-plugin.md)
     - [To add optional features](./plugins/to-add-optional-features.md)
       - [declarative/v1](./plugins/declarative-v1.md)
       - [grafana/v1-alpha](./plugins/grafana-v1-alpha.md)

docs/book/src/faq.md

@@ -8,7 +8,7 @@ After creating a project, usually you will want to extend the Kubernetes APIs an
 The domain is for the group suffix, to explicitly show the resource group category.
 For example, if set `--domain=example.com`:
 ```
-kubebuilder init --domain example.com --repo xxx --plugins=go/v4-alpha
+kubebuilder init --domain example.com --repo xxx --plugins=go/v4
 kubebuilder create api --group mygroup --version v1beta1 --kind Mykind
 ```
 Then the result resource group will be `mygroup.example.com`.

docs/book/src/migration/legacy/v2vsv3.md

@@ -66,15 +66,13 @@ So you want to upgrade your scaffolding to use the latest and greatest features
 <h1> Apple Silicon (M1) </h1>
 
 The current scaffold done by the CLI (`go/v3`) uses [kubernetes-sigs/kustomize][kustomize] v3 which does not provide
-a valid binary for Apple Silicon (`darwin/arm64`). Therefore, you can use the `go/v4-alpha` plugin
+a valid binary for Apple Silicon (`darwin/arm64`). Therefore, you can use the `go/v4` plugin
 instead which provides support for this platform:
 
 ```bash
-kubebuilder init --domain my.domain --repo my.domain/guestbook --plugins=go/v4-alpha
+kubebuilder init --domain my.domain --repo my.domain/guestbook --plugins=go/v4
 ```
 
-**Note**: The `go/v4-alpha` plugin is an unstable version and can have breaking changes in future releases.
-The steps to migrate your project from v2 to v3 using the `alpha` scaffold are the same.
 </aside>
 
 - [Migration Guide v2 to V3][migration-guide-v2-to-v3] **(Recommended)**

docs/book/src/migration/manually_migration_guide_gov3_to_gov4.md

@@ -1,18 +1,18 @@
-# Migration from go/v3 to go/v4-alpha by updating the files manually
+# Migration from go/v3 to go/v4 by updating the files manually
 
-Make sure you understand the [differences between Kubebuilder go/v3 and go/v4-alpha][v3vsv4]
+Make sure you understand the [differences between Kubebuilder go/v3 and go/v4][v3vsv4]
 before continuing.
 
 Please ensure you have followed the [installation guide][quick-start]
 to install the required components.
 
-The following guide describes the manual steps required to upgrade your PROJECT config file to begin using `go/v4-alpha`.
+The following guide describes the manual steps required to upgrade your PROJECT config file to begin using `go/v4`.
 
 This way is more complex, susceptible to errors, and success cannot be assured. Also, by following these steps you will not get the improvements and bug fixes in the default generated project files.
 
 Usually it is suggested to do it manually if you have customized your project and deviated too much from the proposed scaffold. Before continuing, ensure that you understand the note about [project customizations][project-customizations]. Note that you might need to spend more effort to do this process manually than to organize your project customizations. The proposed layout will keep your project maintainable and upgradable with less effort in the future.
 
-The recommended upgrade approach is to follow the [Migration Guide go/v3 to go/v4-alpha][migration-guide-gov3-to-gov4] instead.
+The recommended upgrade approach is to follow the [Migration Guide go/v3 to go/v4][migration-guide-gov3-to-gov4] instead.
 
 ## Migration from project config version "go/v3" to "go/v4"
 
@@ -37,7 +37,7 @@ With:
 
 ```yaml
 layout:
-- go.kubebuilder.io/v4-alpha
+- go.kubebuilder.io/v4
 
 ```
 
@@ -152,15 +152,15 @@ The PROJECT tracks the paths of all APIs used in your project. Ensure that they
 
 ### Update kustomize manifests with the changes made so far
 
-- Update the manifest under `config/` directory with all changes performed in the default scaffold done with `go/v4-alpha` plugin. (see for example `testdata/project-v4/config/`) to get all changes in the
+- Update the manifest under `config/` directory with all changes performed in the default scaffold done with `go/v4` plugin. (see for example `testdata/project-v4/config/`) to get all changes in the
   default scaffolds to be applied on your project
 - Create `config/samples/kustomization.yaml` with all Custom Resources samples specified into `config/samples`. _(see for example `testdata/project-v4/config/samples/kustomization.yaml`)_
 
 <aside class="warning">
 <h1>`config/` directory with changes into the scaffold files</h1>
 
 Note that under the `config/` directory you will find scaffolding changes since using
-`go/v4-alpha` you will ensure that you are no longer using Kustomize v3x.
+`go/v4` you will ensure that you are no longer using Kustomize v3x.
 
 You can mainly compare the `config/` directory from the samples scaffolded under the `testdata`directory by
 checking the differences between the `testdata/project-v3/config/` with `testdata/project-v4/config/` which
@@ -189,11 +189,11 @@ Update the `go.mod` with the changes which can be found in the samples under `te
 ### Verification
 
 In the steps above, you updated your project manually with the goal of ensuring that it follows
-the changes in the layout introduced with the `go/v4-alpha` plugin that update the scaffolds.
+the changes in the layout introduced with the `go/v4` plugin that update the scaffolds.
 
 There is no option to verify that you properly updated the `PROJECT` file of your project. 
-The best way to ensure that everything is updated correctly, would be to initialize a project using the `go/v4-alpha` plugin,
-(ie) using `kubebuilder init --domain tutorial.kubebuilder.io plugins=go/v4-alpha` and generating the same API(s),
+The best way to ensure that everything is updated correctly, would be to initialize a project using the `go/v4` plugin,
+(ie) using `kubebuilder init --domain tutorial.kubebuilder.io plugins=go/v4` and generating the same API(s),
 controller(s), and webhook(s) in order to compare the generated configuration with the manually changed configuration.
 
 Also, after all updates you would run the following commands:

docs/book/src/migration/migration_guide_gov3_to_gov4.md

@@ -1,19 +1,19 @@
-# Migration from go/v3 to go/v4-alpha
+# Migration from go/v3 to go/v4
 
-Make sure you understand the [differences between Kubebuilder go/v3 and go/v4-alpha][v3vsv4]
+Make sure you understand the [differences between Kubebuilder go/v3 and go/v4][v3vsv4]
 before continuing.
 
 Please ensure you have followed the [installation guide][quick-start]
 to install the required components.
 
-The recommended way to migrate a go/v3 project is to create a new go/v4-alpha project and
+The recommended way to migrate a `go/v3` project is to create a new `go/v4` project and
 copy over the API and the reconciliation code. The conversion will end up with a
-project that looks like a native go/v4-alpha project layout (latest version).
+project that looks like a native go/v4 project layout (latest version).
 
 However, in some cases, it's possible to do an in-place upgrade (i.e. reuse the go/v3 project layout, upgrading
-the PROJECT file, and scaffolds manually). For further information see [Migration from go/v3 to go/v4-alpha by updating the files manually][manually-upgrade]
+the PROJECT file, and scaffolds manually). For further information see [Migration from go/v3 to go/v4 by updating the files manually][manually-upgrade]
 
-## Initialize a go/v4-alpha Project
+## Initialize a go/v4 Project
 
 <aside class="note">
 <h1>Project name</h1>
@@ -30,7 +30,7 @@ $ mkdir migration-project-name
 $ cd migration-project-name
 ```
 
-Now, we need to initialize a go/v4-alpha project.  Before we do that, we'll need
+Now, we need to initialize a go/v4 project.  Before we do that, we'll need
 to initialize a new go module if we're not on the `GOPATH`. While technically this is
 not needed inside `GOPATH`, it is still recommended.
 
@@ -50,7 +50,7 @@ module tutorial.kubebuilder.io/migration-project
 Now, we can finish initializing the project with kubebuilder.
 
 ```bash
-kubebuilder init --domain tutorial.kubebuilder.io --plugins=go/v4-alpha
+kubebuilder init --domain tutorial.kubebuilder.io --plugins=go/v4
 ```
 
 <aside class="note">
@@ -119,7 +119,7 @@ Now, let's copy the webhook definition from `api/v1/<kind>_webhook.go` from our
 If there are any manual updates in `main.go` in v3, we need to port the changes to the new `main.go`. We’ll also need to ensure all of needed controller-runtime `schemes` have been registered.
 
 If there are additional manifests added under config directory, port them as well. Please, be aware that
-the new version go/v4-alpha uses Kustomize v5x and no longer Kustomize v4. Therefore, if added customized
+the new version go/v4 uses Kustomize v5x and no longer Kustomize v4. Therefore, if added customized
 implementations in the config you need to ensure that them can work with Kustomize v5 and/if not
 update/upgrade any breaking change that you might face.
 

docs/book/src/migration/multi-group.md

@@ -21,9 +21,9 @@ to modify the default project structure to support it.
 Let's migrate the [CronJob example][cronjob-tutorial].
 
 <aside class="note warning">
-<h1>Using go/v4-alpha</h1>
+<h1>Using go/v4</h1>
 
-If you create your project using go/v4-alpha plugin (you can verify it by looking at the PROJECT file )
+If you create your project using go/v4 plugin (you can verify it by looking at the PROJECT file )
 then, all steps are the same but you need to keep in mind that the api and controllers directory
 path is now under the `pkg` directory instead. So, you need ensure that you update the
 paths accordingly.

docs/book/src/migration/v3vsv4.md

@@ -1,6 +1,6 @@
-# go/v3 vs go/v4-alpha
+# go/v3 vs go/v4
 
-This document covers all breaking changes when migrating from projects built using the plugin go/v3 (default for any scaffold done since `28 Apr 2021`) to the next alpha version of the Golang plugin `go/v4-alpha`.
+This document covers all breaking changes when migrating from projects built using the plugin go/v3 (default for any scaffold done since `28 Apr 2021`) to the next alpha version of the Golang plugin `go/v4`.
 
 The details of all changes (breaking or otherwise) can be found in:
 
@@ -11,7 +11,7 @@ The details of all changes (breaking or otherwise) can be found in:
 
 ## Common changes
 
-- `go/v4-alpha` projects use Kustomize v4x (instead of v3x)
+- `go/v4` projects use Kustomize v5x (instead of v3x)
 - note that some manifests under `config/` directory have been changed in order to no longer use the deprecated Kustomize features
   such as env vars.
 - A `kustomization.yaml` is scaffolded under `config/samples`. This helps simply and flexibly generate sample manifests: `kustomize build config/samples`.
@@ -24,13 +24,13 @@ The details of all changes (breaking or otherwise) can be found in:
 by moving the api(s) under a new directory called `api`, controller(s) under a new directory called `internal` and the `main.go` under a new directory named `cmd`
 
 <aside class="note">
-<H1> TL;DR of the New `go/v4-alpha` Plugin </H1>
+<H1> TL;DR of the New `go/v4` Plugin </H1>
 
-Further details can be found in the [go/v4-alpha plugin section][go/v4-doc]
+Further details can be found in the [go/v4 plugin section][go/v4-doc]
 
 </aside>
 
-## TL;DR of the New `go/v4-alpha` Plugin
+## TL;DR of the New `go/v4` Plugin
 
 **_More details on this can be found at [here][kb-releases], but for the highlights, check below_**
 
@@ -49,7 +49,7 @@ For example, you should refrain from moving the scaffolded files, doing so will
 
 </aside>
 
-## Migrating to Kubebuilder go/v4-alpha
+## Migrating to Kubebuilder go/v4
 
 If you want to upgrade your scaffolding to use the latest and greatest features then, follow the guide
 which will cover the steps in the most straightforward way to allow you to upgrade your project to get all
@@ -59,14 +59,14 @@ latest changes and improvements.
 <h1> Apple Silicon (M1) </h1>
 
 The current scaffold done by the CLI (`go/v3`) uses [kubernetes-sigs/kustomize][kustomize] v3 which does not provide
-a valid binary for Apple Silicon (`darwin/arm64`). Therefore, you can use the `go/v4-alpha` plugin
+a valid binary for Apple Silicon (`darwin/arm64`). Therefore, you can use the `go/v4` plugin
 instead which provides support for this platform:
 
 ```bash
-kubebuilder init --domain my.domain --repo my.domain/guestbook --plugins=go/v4-alpha
+kubebuilder init --domain my.domain --repo my.domain/guestbook --plugins=go/v4
 ```
 
-**Note**: The `go/v4-alpha` plugin is an unstable version and can have breaking changes in future releases.
+**Note**: The `go/v4` plugin is an unstable version and can have breaking changes in future releases.
 
 </aside>
 
@@ -78,7 +78,7 @@ If you want to use the latest version of Kubebuilder CLI without changing your s
 
 This way is more complex, susceptible to errors, and success cannot be assured. Also, by following these steps you will not get the improvements and bug fixes in the default generated project files.
 
-- [Migrating to go/v4-alpha by updating the files manually][manually-upgrade]
+- [Migrating to go/v4 by updating the files manually][manually-upgrade]
 
 [plugins-phase1-design-doc]: https://github.com/kubernetes-sigs/kubebuilder/blob/master/designs/extensible-cli-and-scaffolding-plugins-phase-1.md
 [plugins-phase1-design-doc-1.5]: https://github.com/kubernetes-sigs/kubebuilder/blob/master/designs/extensible-cli-and-scaffolding-plugins-phase-1-5.md

docs/book/src/plugins/creating-plugins.md

@@ -147,8 +147,8 @@ You might want for example to overwrite a scaffold done by using the option:
 	f.IfExistsAction = machinery.OverwriteFile
 ```
 
-Let's imagine that you would like to have a helper plugin that would be called in a chain with `go/v4-alpha` to add customizations on top.
-Therefore after we generate the code calling the subcommand to `init` from `go/v4-alpha` we would like to overwrite the Makefile to change this scaffold via our plugin.
+Let's imagine that you would like to have a helper plugin that would be called in a chain with `go/v4` to add customizations on top.
+Therefore after we generate the code calling the subcommand to `init` from `go/v4` we would like to overwrite the Makefile to change this scaffold via our plugin.
 In this way, we would implement the Bollerplate for our Makefile and then use this option to ensure that it would be overwritten.
 
 See [example of deploy-image][example-of-deploy-image-1].