You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/book/src/migration/manually_migration_guide_gov3_to_gov4.md
+10-10Lines changed: 10 additions & 10 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,18 +1,18 @@
1
-
# Migration from go/v3 to go/v4-alpha by updating the files manually
1
+
# Migration from go/v3 to go/v4 by updating the files manually
2
2
3
-
Make sure you understand the [differences between Kubebuilder go/v3 and go/v4-alpha][v3vsv4]
3
+
Make sure you understand the [differences between Kubebuilder go/v3 and go/v4][v3vsv4]
4
4
before continuing.
5
5
6
6
Please ensure you have followed the [installation guide][quick-start]
7
7
to install the required components.
8
8
9
-
The following guide describes the manual steps required to upgrade your PROJECT config file to begin using `go/v4-alpha`.
9
+
The following guide describes the manual steps required to upgrade your PROJECT config file to begin using `go/v4`.
10
10
11
11
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.
12
12
13
13
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.
14
14
15
-
The recommended upgrade approach is to follow the [Migration Guide go/v3 to go/v4-alpha][migration-guide-gov3-to-gov4] instead.
15
+
The recommended upgrade approach is to follow the [Migration Guide go/v3 to go/v4][migration-guide-gov3-to-gov4] instead.
16
16
17
17
## Migration from project config version "go/v3" to "go/v4"
18
18
@@ -37,7 +37,7 @@ With:
37
37
38
38
```yaml
39
39
layout:
40
-
- go.kubebuilder.io/v4-alpha
40
+
- go.kubebuilder.io/v4
41
41
42
42
```
43
43
@@ -152,15 +152,15 @@ The PROJECT tracks the paths of all APIs used in your project. Ensure that they
152
152
153
153
### Update kustomize manifests with the changes made so far
154
154
155
-
- 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
155
+
- 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
156
156
default scaffolds to be applied on your project
157
157
- Create `config/samples/kustomization.yaml` with all Custom Resources samples specified into `config/samples`. _(see for example `testdata/project-v4/config/samples/kustomization.yaml`)_
158
158
159
159
<aside class="warning">
160
160
<h1>`config/` directory with changes into the scaffold files</h1>
161
161
162
162
Note that under the `config/` directory you will find scaffolding changes since using
163
-
`go/v4-alpha` you will ensure that you are no longer using Kustomize v3x.
163
+
`go/v4` you will ensure that you are no longer using Kustomize v3x.
164
164
165
165
You can mainly compare the `config/` directory from the samples scaffolded under the `testdata`directory by
166
166
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
189
189
### Verification
190
190
191
191
In the steps above, you updated your project manually with the goal of ensuring that it follows
192
-
the changes in the layout introduced with the `go/v4-alpha` plugin that update the scaffolds.
192
+
the changes in the layout introduced with the `go/v4` plugin that update the scaffolds.
193
193
194
194
There is no option to verify that you properly updated the `PROJECT` file of your project.
195
-
The best way to ensure that everything is updated correctly, would be to initialize a project using the `go/v4-alpha` plugin,
196
-
(ie) using `kubebuilder init --domain tutorial.kubebuilder.io plugins=go/v4-alpha` and generating the same API(s),
195
+
The best way to ensure that everything is updated correctly, would be to initialize a project using the `go/v4` plugin,
196
+
(ie) using `kubebuilder init --domain tutorial.kubebuilder.io plugins=go/v4` and generating the same API(s),
197
197
controller(s), and webhook(s) in order to compare the generated configuration with the manually changed configuration.
198
198
199
199
Also, after all updates you would run the following commands:
Copy file name to clipboardExpand all lines: docs/book/src/migration/migration_guide_gov3_to_gov4.md
+9-9Lines changed: 9 additions & 9 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,19 +1,19 @@
1
-
# Migration from go/v3 to go/v4-alpha
1
+
# Migration from go/v3 to go/v4
2
2
3
-
Make sure you understand the [differences between Kubebuilder go/v3 and go/v4-alpha][v3vsv4]
3
+
Make sure you understand the [differences between Kubebuilder go/v3 and go/v4][v3vsv4]
4
4
before continuing.
5
5
6
6
Please ensure you have followed the [installation guide][quick-start]
7
7
to install the required components.
8
8
9
-
The recommended way to migrate a go/v3 project is to create a new go/v4-alpha project and
9
+
The recommended way to migrate a `go/v3` project is to create a new `go/v4` project and
10
10
copy over the API and the reconciliation code. The conversion will end up with a
11
-
project that looks like a native go/v4-alpha project layout (latest version).
11
+
project that looks like a native go/v4 project layout (latest version).
12
12
13
13
However, in some cases, it's possible to do an in-place upgrade (i.e. reuse the go/v3 project layout, upgrading
14
-
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]
14
+
the PROJECT file, and scaffolds manually). For further information see [Migration from go/v3 to go/v4 by updating the files manually][manually-upgrade]
15
15
16
-
## Initialize a go/v4-alpha Project
16
+
## Initialize a go/v4 Project
17
17
18
18
<asideclass="note">
19
19
<h1>Project name</h1>
@@ -30,7 +30,7 @@ $ mkdir migration-project-name
30
30
$ cd migration-project-name
31
31
```
32
32
33
-
Now, we need to initialize a go/v4-alpha project. Before we do that, we'll need
33
+
Now, we need to initialize a go/v4 project. Before we do that, we'll need
34
34
to initialize a new go module if we're not on the `GOPATH`. While technically this is
35
35
not needed inside `GOPATH`, it is still recommended.
@@ -119,7 +119,7 @@ Now, let's copy the webhook definition from `api/v1/<kind>_webhook.go` from our
119
119
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.
120
120
121
121
If there are additional manifests added under config directory, port them as well. Please, be aware that
122
-
the new version go/v4-alpha uses Kustomize v5x and no longer Kustomize v4. Therefore, if added customized
122
+
the new version go/v4 uses Kustomize v5x and no longer Kustomize v4. Therefore, if added customized
123
123
implementations in the config you need to ensure that them can work with Kustomize v5 and/if not
124
124
update/upgrade any breaking change that you might face.
Copy file name to clipboardExpand all lines: docs/book/src/migration/v3vsv4.md
+11-11Lines changed: 11 additions & 11 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,6 +1,6 @@
1
-
# go/v3 vs go/v4-alpha
1
+
# go/v3 vs go/v4
2
2
3
-
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`.
3
+
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`.
4
4
5
5
The details of all changes (breaking or otherwise) can be found in:
6
6
@@ -11,7 +11,7 @@ The details of all changes (breaking or otherwise) can be found in:
11
11
12
12
## Common changes
13
13
14
-
-`go/v4-alpha` projects use Kustomize v4x (instead of v3x)
14
+
-`go/v4` projects use Kustomize v5x (instead of v3x)
15
15
- note that some manifests under `config/` directory have been changed in order to no longer use the deprecated Kustomize features
16
16
such as env vars.
17
17
- 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:
24
24
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`
25
25
26
26
<asideclass="note">
27
-
<H1> TL;DR of the New `go/v4-alpha` Plugin </H1>
27
+
<H1> TL;DR of the New `go/v4` Plugin </H1>
28
28
29
-
Further details can be found in the [go/v4-alpha plugin section][go/v4-doc]
29
+
Further details can be found in the [go/v4 plugin section][go/v4-doc]
30
30
31
31
</aside>
32
32
33
-
## TL;DR of the New `go/v4-alpha` Plugin
33
+
## TL;DR of the New `go/v4` Plugin
34
34
35
35
**_More details on this can be found at [here][kb-releases], but for the highlights, check below_**
36
36
@@ -49,7 +49,7 @@ For example, you should refrain from moving the scaffolded files, doing so will
49
49
50
50
</aside>
51
51
52
-
## Migrating to Kubebuilder go/v4-alpha
52
+
## Migrating to Kubebuilder go/v4
53
53
54
54
If you want to upgrade your scaffolding to use the latest and greatest features then, follow the guide
55
55
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.
59
59
<h1> Apple Silicon (M1) </h1>
60
60
61
61
The current scaffold done by the CLI (`go/v3`) uses [kubernetes-sigs/kustomize][kustomize] v3 which does not provide
62
-
a valid binary for Apple Silicon (`darwin/arm64`). Therefore, you can use the `go/v4-alpha` plugin
62
+
a valid binary for Apple Silicon (`darwin/arm64`). Therefore, you can use the `go/v4` plugin
**Note**: The `go/v4-alpha` plugin is an unstable version and can have breaking changes in future releases.
69
+
**Note**: The `go/v4` plugin is an unstable version and can have breaking changes in future releases.
70
70
71
71
</aside>
72
72
@@ -78,7 +78,7 @@ If you want to use the latest version of Kubebuilder CLI without changing your s
78
78
79
79
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.
80
80
81
-
-[Migrating to go/v4-alpha by updating the files manually][manually-upgrade]
81
+
-[Migrating to go/v4 by updating the files manually][manually-upgrade]
Copy file name to clipboardExpand all lines: docs/book/src/plugins/creating-plugins.md
+2-2Lines changed: 2 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -147,8 +147,8 @@ You might want for example to overwrite a scaffold done by using the option:
147
147
f.IfExistsAction = machinery.OverwriteFile
148
148
```
149
149
150
-
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.
151
-
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.
150
+
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.
151
+
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.
152
152
In this way, we would implement the Bollerplate for our Makefile and then use this option to ensure that it would be overwritten.
153
153
154
154
See [example of deploy-image][example-of-deploy-image-1].
0 commit comments