@@ -141,17 +141,6 @@ The `vendor` directory is optional. It is still present in projects
141141because it avoids downloading sources during CI builds. If this is no
142142longer deemed necessary, then a project can also remove the directory.
143143
144- When using packages that are part of the Kubernetes source code, the
145- commands above are not enough because the [ lack of semantic
146- versioning] ( https://github.com/kubernetes/kubernetes/issues/72638 )
147- prevents ` go mod ` from finding newer releases. Importing directly from
148- ` kubernetes/kubernetes ` also needs ` replace ` statements to override
149- the fake ` v0.0.0 ` versions
150- (https://github.com/kubernetes/kubernetes/issues/79384 ). The
151- ` go-get-kubernetes.sh ` script can be used to update all packages in
152- lockstep to a different Kubernetes version. It takes a single version
153- number like "1.16.0".
154-
155144Conversion of a repository that uses ` dep ` to ` go mod ` can be done with:
156145
157146 GO111MODULE=on go mod init
@@ -160,3 +149,18 @@ Conversion of a repository that uses `dep` to `go mod` can be done with:
160149 GO111MODULE=on go mod vendor
161150 git rm -f Gopkg.toml Gopkg.lock
162151 git add go.mod go.sum vendor
152+
153+ ### Updating Kubernetes dependencies
154+
155+ When using packages that are part of the Kubernetes source code, the
156+ commands above are not enough because the [ lack of semantic
157+ versioning] ( https://github.com/kubernetes/kubernetes/issues/72638 )
158+ prevents ` go mod ` from finding newer releases. Importing directly from
159+ ` kubernetes/kubernetes ` also needs ` replace ` statements to override
160+ the fake ` v0.0.0 ` versions
161+ (https://github.com/kubernetes/kubernetes/issues/79384 ). The
162+ ` go-get-kubernetes.sh ` script can be used to update all packages in
163+ lockstep to a different Kubernetes version. Example usage:
164+ ```
165+ $ ./release-tools/go-get-kubernetes.sh 1.16.4
166+ ```
0 commit comments