Revert "Return a meaningful message if we hit the rate-limiter of GitHub"

Return a meaningful message if we hit the rate-limiter of GitHub

Makefile

@@ -12,6 +12,7 @@ MYGOBIN = $(shell go env GOPATH)/bin
 endif
 export PATH := $(MYGOBIN):$(PATH)
 MODULES := '"cmd/config" "api/" "kustomize/" "kyaml/"'
+LATEST_V4_RELEASE=v4.3.0
 
 # Provide defaults for REPO_OWNER and REPO_NAME if not present.
 # Typically these values would be provided by Prow.
@@ -31,7 +32,7 @@ verify-kustomize: \
 	lint-kustomize \
 	test-unit-kustomize-all \
 	test-examples-kustomize-against-HEAD \
-	test-examples-kustomize-against-4.1
+	test-examples-kustomize-against-v4-release
 
 # The following target referenced by a file in
 # https://github.com/kubernetes/test-infra/tree/master/config/jobs/kubernetes-sigs/kustomize
@@ -44,7 +45,7 @@ prow-presubmit-check: \
 	test-unit-cmd-all \
 	test-go-mod \
 	test-examples-kustomize-against-HEAD \
-	test-examples-kustomize-against-4.1
+	test-examples-kustomize-against-v4-release
 
 .PHONY: verify-kustomize-e2e
 verify-kustomize-e2e: test-examples-e2e-kustomize
@@ -278,8 +279,8 @@ test-examples-kustomize-against-HEAD: $(MYGOBIN)/kustomize $(MYGOBIN)/mdrip
 	./hack/testExamplesAgainstKustomize.sh HEAD
 
 .PHONY:
-test-examples-kustomize-against-4.1: $(MYGOBIN)/mdrip
-	./hack/testExamplesAgainstKustomize.sh v4@v4.1.2
+test-examples-kustomize-against-v4-release: $(MYGOBIN)/mdrip
+	./hack/testExamplesAgainstKustomize.sh v4@$(LATEST_V4_RELEASE)
 
 # linux only.
 # This is for testing an example plugin that

api/go.mod

@@ -14,3 +14,5 @@ require (
 	sigs.k8s.io/kustomize/kyaml v0.11.1
 	sigs.k8s.io/yaml v1.2.0
 )
+
+replace sigs.k8s.io/kustomize/kyaml => ../kyaml

api/go.sum

@@ -223,8 +223,6 @@ k8s.io/gengo v0.0.0-20200413195148-3a45101e95ac/go.mod h1:ezvh/TsK7cY6rbqRK0oQQ8
 k8s.io/klog/v2 v2.0.0/go.mod h1:PBfzABfn139FHAV07az/IF9Wp1bkk3vpT2XSJ76fSDE=
 k8s.io/kube-openapi v0.0.0-20210421082810-95288971da7e h1:KLHHjkdQFomZy8+06csTWZ0m1343QqxZhR2LJ1OxCYM=
 k8s.io/kube-openapi v0.0.0-20210421082810-95288971da7e/go.mod h1:vHXdDvt9+2spS2Rx9ql3I8tycm3H9FDfdUoIuKCefvw=
-sigs.k8s.io/kustomize/kyaml v0.11.1 h1:MWihd9syKG7VQnAzr/OpKb94FvH+cw96nEV1u3it7pI=
-sigs.k8s.io/kustomize/kyaml v0.11.1/go.mod h1:FTJxEZ86ScK184NpGSAQcfEqee0nul8oLCK30D47m4E=
 sigs.k8s.io/structured-merge-diff/v4 v4.0.2/go.mod h1:bJZC9H9iH24zzfZ/41RGcq60oK1F7G282QMXDPYydCw=
 sigs.k8s.io/yaml v1.2.0 h1:kr/MCeFWJWTwyaHoR9c8EjH9OumOmoF9YGiZd7lFm/Q=
 sigs.k8s.io/yaml v1.2.0/go.mod h1:yfXDCHCao9+ENCvLSE62v9VSji2MKu5jeNfTrofGhJc=

cmd/config/go.mod

@@ -18,3 +18,5 @@ require (
 	k8s.io/kube-openapi v0.0.0-20210421082810-95288971da7e
 	sigs.k8s.io/kustomize/kyaml v0.11.1
 )
+
+replace sigs.k8s.io/kustomize/kyaml => ../../kyaml

cmd/config/go.sum

@@ -245,8 +245,6 @@ k8s.io/gengo v0.0.0-20200413195148-3a45101e95ac/go.mod h1:ezvh/TsK7cY6rbqRK0oQQ8
 k8s.io/klog/v2 v2.0.0/go.mod h1:PBfzABfn139FHAV07az/IF9Wp1bkk3vpT2XSJ76fSDE=
 k8s.io/kube-openapi v0.0.0-20210421082810-95288971da7e h1:KLHHjkdQFomZy8+06csTWZ0m1343QqxZhR2LJ1OxCYM=
 k8s.io/kube-openapi v0.0.0-20210421082810-95288971da7e/go.mod h1:vHXdDvt9+2spS2Rx9ql3I8tycm3H9FDfdUoIuKCefvw=
-sigs.k8s.io/kustomize/kyaml v0.11.1 h1:MWihd9syKG7VQnAzr/OpKb94FvH+cw96nEV1u3it7pI=
-sigs.k8s.io/kustomize/kyaml v0.11.1/go.mod h1:FTJxEZ86ScK184NpGSAQcfEqee0nul8oLCK30D47m4E=
 sigs.k8s.io/structured-merge-diff/v4 v4.0.2/go.mod h1:bJZC9H9iH24zzfZ/41RGcq60oK1F7G282QMXDPYydCw=
 sigs.k8s.io/yaml v1.2.0 h1:kr/MCeFWJWTwyaHoR9c8EjH9OumOmoF9YGiZd7lFm/Q=
 sigs.k8s.io/yaml v1.2.0/go.mod h1:yfXDCHCao9+ENCvLSE62v9VSji2MKu5jeNfTrofGhJc=

cmd/gorepomod/internal/git/runner.go

@@ -278,12 +278,13 @@ func (gr *Runner) CheckoutReleaseBranch(
 		return nil
 	}
 	gr.comment("creating branch")
-	// The branch doesn't exist.  Create it.
-	out, err := gr.run(noHarmDone, "checkout", "-b", branch)
+	// The branch doesn't exist remotely.  Create or reset it locally.
+	out, err := gr.run(noHarmDone, "checkout", "-B", branch)
 	if err != nil {
 		return err
 	}
-	if !strings.Contains(out, "Switched to a new branch ") {
+	// Expected strings: "Switched to a new branch" or "Switched to and reset branch"
+	if !strings.Contains(out, "Switched to") {
 		return fmt.Errorf("unexpected branch creation output: %q", out)
 	}
 	return nil

cmd/pluginator/go.mod

@@ -6,8 +6,10 @@ require (
 	github.com/rakyll/statik v0.1.7
 	github.com/spf13/cobra v1.0.0
 	github.com/stretchr/testify v1.5.1
-	sigs.k8s.io/kustomize/api v0.8.11
+	sigs.k8s.io/kustomize/api v0.9.0
 	sigs.k8s.io/kustomize/kyaml v0.11.1
 )
 
 replace sigs.k8s.io/kustomize/api => ../../api
+
+replace sigs.k8s.io/kustomize/kyaml => ../../kyaml

cmd/pluginator/go.sum

@@ -228,8 +228,6 @@ k8s.io/gengo v0.0.0-20200413195148-3a45101e95ac/go.mod h1:ezvh/TsK7cY6rbqRK0oQQ8
 k8s.io/klog/v2 v2.0.0/go.mod h1:PBfzABfn139FHAV07az/IF9Wp1bkk3vpT2XSJ76fSDE=
 k8s.io/kube-openapi v0.0.0-20210421082810-95288971da7e h1:KLHHjkdQFomZy8+06csTWZ0m1343QqxZhR2LJ1OxCYM=
 k8s.io/kube-openapi v0.0.0-20210421082810-95288971da7e/go.mod h1:vHXdDvt9+2spS2Rx9ql3I8tycm3H9FDfdUoIuKCefvw=
-sigs.k8s.io/kustomize/kyaml v0.11.1 h1:MWihd9syKG7VQnAzr/OpKb94FvH+cw96nEV1u3it7pI=
-sigs.k8s.io/kustomize/kyaml v0.11.1/go.mod h1:FTJxEZ86ScK184NpGSAQcfEqee0nul8oLCK30D47m4E=
 sigs.k8s.io/structured-merge-diff/v4 v4.0.2/go.mod h1:bJZC9H9iH24zzfZ/41RGcq60oK1F7G282QMXDPYydCw=
 sigs.k8s.io/yaml v1.2.0 h1:kr/MCeFWJWTwyaHoR9c8EjH9OumOmoF9YGiZd7lFm/Q=
 sigs.k8s.io/yaml v1.2.0/go.mod h1:yfXDCHCao9+ENCvLSE62v9VSji2MKu5jeNfTrofGhJc=

kustomize/go.mod

@@ -8,7 +8,7 @@ require (
 	github.com/spf13/cobra v1.0.0
 	github.com/spf13/pflag v1.0.5
 	github.com/stretchr/testify v1.7.0
-	sigs.k8s.io/kustomize/api v0.8.11
+	sigs.k8s.io/kustomize/api v0.9.0
 	sigs.k8s.io/kustomize/cmd/config v0.10.0
 	sigs.k8s.io/kustomize/kyaml v0.11.1
 	sigs.k8s.io/yaml v1.2.0
@@ -20,3 +20,7 @@ exclude (
 )
 
 replace sigs.k8s.io/kustomize/api => ../api
+
+replace sigs.k8s.io/kustomize/cmd/config => ../cmd/config
+
+replace sigs.k8s.io/kustomize/kyaml => ../kyaml

kustomize/go.sum

@@ -253,10 +253,6 @@ k8s.io/gengo v0.0.0-20200413195148-3a45101e95ac/go.mod h1:ezvh/TsK7cY6rbqRK0oQQ8
 k8s.io/klog/v2 v2.0.0/go.mod h1:PBfzABfn139FHAV07az/IF9Wp1bkk3vpT2XSJ76fSDE=
 k8s.io/kube-openapi v0.0.0-20210421082810-95288971da7e h1:KLHHjkdQFomZy8+06csTWZ0m1343QqxZhR2LJ1OxCYM=
 k8s.io/kube-openapi v0.0.0-20210421082810-95288971da7e/go.mod h1:vHXdDvt9+2spS2Rx9ql3I8tycm3H9FDfdUoIuKCefvw=
-sigs.k8s.io/kustomize/cmd/config v0.10.0 h1:6XPkaOu9eFdvrcqHpfmYAKoBvE01JdvsTVvtDuAFM+8=
-sigs.k8s.io/kustomize/cmd/config v0.10.0/go.mod h1:XS4NFKucjk0/+nPKJwSMoZYCjey2PB0ipNoZabXUFPU=
-sigs.k8s.io/kustomize/kyaml v0.11.1 h1:MWihd9syKG7VQnAzr/OpKb94FvH+cw96nEV1u3it7pI=
-sigs.k8s.io/kustomize/kyaml v0.11.1/go.mod h1:FTJxEZ86ScK184NpGSAQcfEqee0nul8oLCK30D47m4E=
 sigs.k8s.io/structured-merge-diff/v4 v4.0.2/go.mod h1:bJZC9H9iH24zzfZ/41RGcq60oK1F7G282QMXDPYydCw=
 sigs.k8s.io/yaml v1.2.0 h1:kr/MCeFWJWTwyaHoR9c8EjH9OumOmoF9YGiZd7lFm/Q=
 sigs.k8s.io/yaml v1.2.0/go.mod h1:yfXDCHCao9+ENCvLSE62v9VSji2MKu5jeNfTrofGhJc=

proposals/00-00-template.md

@@ -0,0 +1,166 @@
+<!--
+**Note:** When your proposal is complete, all of these comment blocks should be removed.
+
+To get started with this template:
+
+- [ ] **Make a copy of this file.**
+  Name it `YY-MM-short-descriptive-title.md` (where `YY-MM` is the current year and month).
+- [ ] **Fill out this file as best you can.**
+  At minimum, you should fill in the "Summary" and "Motivation" sections.
+- [ ] **Create a PR.**
+  Ping `@kubernetes-sigs/kustomize-admins` and `@kubernetes-sigs/kustomize-maintainers`.
+-->
+
+# Your short, descriptive title
+
+**Authors**: <!-- Your github handle -->
+
+**Reviewers**: <!-- List at least one Kustomize approver (https://github.com/kubernetes-sigs/kustomize/blob/master/OWNERS#L2) -->
+
+**Status**: implementable
+<!--
+In general, all proposals made should be merged for the record, whether or not they are accepted.
+Use the status field to record the results of the latest review:
+- implementable: The default for this repo. If the proposal is merged, you can start working on it.
+- deferred: The proposal may be accepted in the future, but it has been shelved for the time being.
+A new PR must be opened to update the proposal and gain reviewer consensus before work can begin.
+- withdrawn: The author changed their mind and no longer wants to pursue the proposal.
+A new PR must be opened to update the proposal and gain reviewer consensus before work can begin.
+- rejected: This proposal should not be implemented.
+- replaced: If you submit a new proposal that supersedes an older one,
+update the older one's status to "replaced by <link>".
+-->
+
+## Summary
+
+<!--
+In one short paragraph, summarize why this change is important to Kustomize users.
+-->
+
+## Motivation
+
+<!--
+If this proposal is an expansion of an existing GitHub issue, link to it here.
+-->
+
+**Goals:**
+<!--
+List the specific goals of the proposal. What is it trying to achieve? How will we
+know that this has succeeded?
+-->
+1. A goal
+1. Another goal
+
+
+**Non-goals:**
+<!--
+What is out of scope for this proposal? Listing non-goals helps to focus discussion
+and make progress.
+-->
+1. A non-goal
+1. Another non-goal
+
+## Proposal
+
+<!--
+This is where we get down to the specifics of what the proposal actually is.
+Include enough information to illustrate your proposal, but try not to
+overwhelm reviewers with details. Focus on APIs and interfaces rather than implementation details,
+e.g.:
+- Does this proposal require new kinds, fields or CLI flags?
+- Will this feature require extending the public interface of Kustomize's Go packages?
+(it's ok if you're not sure yet)
+
+A proof of concept PR is NOT required but is preferable to including large amounts of code
+inline here, if you feel such implementation details are required to adequately explain your design.
+If you have a PR, link to it at the top of this section.
+-->
+
+### User Stories
+<!--
+Describe what people will be able to do if this KEP is implemented. If different user personas
+will use the feature differently, consider writing separate stories for each.
+Include as much detail as possible so that people can understand the "how" of the system.
+The goal here is to make this feel real for users without getting bogged down.
+-->
+
+#### Story 1
+
+Scenario summary: As a [end user, extension developer, ...], I want to [...]
+<!--
+A walkthrough of what it will look like for a user to take advantage of the new feature.
+Include the the steps the user will take and samples of the commands they'll run
+and config they'll use.
+-->
+
+#### Story 2
+
+Scenario summary: As a [end user, extension developer, ...], I want to [...]
+<!--
+A walkthrough of what it will look like for a user to take advantage of the new feature.
+Include the the steps the user will take and samples of the commands they'll run
+and config they'll use.
+-->
+
+### Risks and Mitigations
+<!--
+What are the risks of this proposal, and how do we mitigate? Think broadly.
+For example, consider both security, end-user privacy, and how this will
+impact the larger Kubernetes ecosystem.
+-->
+
+### Dependencies
+<!--
+Kustomize tightly controls its Go dependencies in order to remain approved for
+integration into kubectl. It cannot depend directly on kubectl or apimachinery code.
+Identify any new Go dependencies this proposal will require Kustomize to pull in.
+If any of them are large, is there another option?
+-->
+
+### Scalability
+<!--
+Is this feature expected to have a performance impact?
+Explain to what extent and under what conditions.
+-->
+
+## Drawbacks
+<!--
+Why should this proposal _not_ be implemented?
+-->
+
+## Alternatives
+<!--
+What other approaches did you consider, and why did you rule them out? Be concise,
+but do include enough information to express the idea and why it was not acceptable.
+-->
+
+## Rollout Plan
+<!--
+Depending on the scope of the features and the risks enabling it implies,
+you may need to use a formal graduation process. If you don't think this is
+necessary, explain why here, and delete the alpha/beta/GA headings below.
+-->
+
+### Alpha
+<!--
+New Kinds should be introduced with an alpha group version.
+New major features should often be gated by an alpha flag at first.
+New transformers can be introduced for use in the generators/validators/transformers fields
+before they get their own top-level field in Kustomization.
+-->
+
+- Will the feature be gated by an "alpha" flag? Which one?
+- Will the feature be available in `kubectl kustomize` during alpha? Why or why not?
+
+### Beta
+<!--
+If the alpha was not available in `kubectl kustomize`, you need a beta phase where it is.
+Full parity with `kubectl kustomize` is required at this stage.
+-->
+
+### GA
+<!--
+You should generally wait at least two `kubectl` release cycles before promotion to GA,
+to ensure that the broader user base has time to try the feature and provide feedback.
+For example, if your feature first appears in kubectl 1.23, promote it in 1.25 or later.
+-->

proposals/README.md

@@ -0,0 +1,48 @@
+# Kustomize Enhancement Proposal Processes
+
+So you want to propose an enhancement to Kustomize—awesome! Choose the option below that best fits the scope of your idea. Before you get started, it's a good idea to review the list of [eschewed features](https://kubectl.docs.kubernetes.io/faq/kustomize/eschewedfeatures).
+
+[SIG CLI]: https://github.com/kubernetes/community/tree/master/sig-cli
+[Enhancements repo]: https://github.com/kubernetes/enhancements
+
+### Option 1: Github issue
+
+Small, straightforward enhancements can be proposed in regular GitHub issues. As a rule of thumb, the enhancement should be resolvable in a single PR that is at most size L.
+
+**Example features**:
+- a new Kustomization field that does something very straightforward, like annotating resources
+- a new option for an existing built-in transformer
+
+**Instructions**: [Open an issue](https://github.com/kubernetes-sigs/kustomize/issues/new?labels=kind%2Ffeature&template=feature_request.md)
+
+### Option 2: Mini (In-Repo) Enhancement Proposal
+
+If your feature may be controversial or has a lot of details to explain, you should write it up as a mini enhancement proposal on this repo. This process is still relatively lightweight, but allows for more in-depth discussion of multiple details. Because it is submitted as a PR, reviewers can comment on individual lines of the proposal, facilitating discussion. The PR will be merged whether the feature is accepted or rejected, creating a record of the decisions.
+
+Since the proposal template is a subset of what's required for the full KEP process, this can also be a good option if you're unsure whether your proposal is of general interest to [SIG-CLI]. You can use it to get preliminary feedback from the Kustomize team before bringing a full-fledged KEP to the SIG.
+
+**Example features**:
+- a new built-in transformer with several configurable options
+- a feature that will bring in a significant new dependency
+- a feature that introduces a new class of behavior, such as manipulating data within an opaque resource field
+- a new build process that does not affect `kubectl kustomize`
+
+**Instructions**:
+1. Make a copy of [00-00-template.md](00-00-template.md) and rename it with the current date (e.g. 21-08) and a succinct title.
+1. Fill out the template.
+1. Submit it for review as a PR.
+1. (Optional) Present your proposal at a biweekly [SIG-CLI] meeting. This can be a good way to get more traction for your proposal. Your presentation should be a quick summary to help folks understand whether the proposal is relevant to them.
+
+### Option 3: Kubernetes Enhancement Proposal (KEP)
+
+If your feature changes behaviour in a way that has significance for `kubectl kustomize`, particularly in terms of security, you will need to follow the full KEP process and get buy-in from [SIG-CLI] leadership in addition to Kustomize maintainers. Note that you can still submit a mini (in-repo) enhancement proposal as a first step to get preliminary feedback, including on whether a full KEP is required.
+
+**Example features**:
+- a feature with significant privacy or security implications to work out
+- a feature that is not purely localized to the Kustomize binary on the end user's machine (e.g. downloads something remote, executes something external)
+
+**Instructions**:
+1. Follow the process on the [Enhancements repo]. Be sure to put your KEP in the directory for SIG-CLI.
+1. (Strongly recommended) Send a link to your KEP to the [SIG-CLI] mailing list.
+1. (Strongly recommended) Present your KEP at a biweekly [SIG-CLI] meeting. Your presentation should be a quick summary to help folks understand whether the KEP is relevant to them.
+1. After your KEP is accepted, remember to update its metadata as your feature proceeds through the release process.

releasing/README.md

@@ -15,6 +15,20 @@
 This document describes how to perform a [semver release]
 of one of the several [Go modules] in this repository.
 
+#### semver review
+
+Go's [semver]-compatible version tags take the form `v{major}.{minor}.{patch}`:
+
+| major | minor | patch |
+| :---:   | :---:  | :---: |
+| API change | enhancements | bug fixes |
+| manual update | maybe auto-update | auto-update encouraged |
+
+ - If there are only bug fixes or refactors, increment `patch` from whatever it is now.
+ - If there are new features, increment  `minor`.
+ - If there's an API change (either the Go API or the CLI behavior
+   with respect to CLI arguments and flags), increment `major`.
+
 ## Release sequence
 
 The dependencies determine the release order:
@@ -28,10 +42,17 @@ The dependencies determine the release order:
 
 Thus, do `kyaml` first, then `cmd/config`, etc.
 
+## Prep work
+
+#### Prepare your source directory
+
+The release scripts expect Kustomize code to be cloned at a path ending in `sigs.k8s.io/kustomize`. Run all commands from that directory unless otherwise specified.
+
 #### Consider fetching new OpenAPI data
 The Kubernetes OpenAPI data changes no more frequently than once per quarter.
 You can check the current builtin versions that kustomize is using with the
 following command.
+
 ```
 kustomize openapi info
 ```
@@ -39,46 +60,10 @@ kustomize openapi info
 Instructions on how to get a new OpenAPI sample can be found in the
 [OpenAPI Readme].
 
-## Prep work
-
-#### Make some helper functions
+#### Load some helper functions
 
 ```
-function createBranch {
-  branch=$1
-  echo "Making branch $branch : \"$title\""
-  git branch -D $branch  # delete if it exists
-  git checkout -b $branch
-  git commit -a -m "$title"
-  git push -f origin $branch
-}
-```
-
-```
-function createPr {
-  gh pr create --title "$title" --body "ALLOW_MODULE_SPAN" --base master
-}
-```
-
-```
-function refreshMaster {
-  git checkout master
-  git fetch upstream
-  git rebase upstream/master
-}
-```
-
-```
-function testKustomizeRepo {
-  make prow-presubmit-check >& /tmp/k.txt
-  local code=$?
-  if [ $code -ne 0 ]; then
-    echo "**** FAILURE ******************"
-    tail /tmp/k.txt
-  else
-    echo "LGTM"
-  fi
-}
+source releasing/helpers.sh
 ```
 
 #### Install the release tool
@@ -101,18 +86,21 @@ echo $GITHUB_TOKEN | gh auth login --scopes repo --with-token
 #### Establish clean state
 
 ```
-cd ~/gopath/src/sigs.k8s.io/kustomize
 refreshMaster
 testKustomizeRepo
 ```
 
+While you're waiting for the tests, review the commit log. Based on the changes to be included in this release, decide whether a patch, minor or major version bump is needed: [semver review].
+
 kyaml has no intra-repo deps, so if the tests pass,
 it can just be released.
 
-Release it:
+#### Release it
+
+The default increment is a new patch version.
 
 ```
-gorepomod release kyaml --doIt
+gorepomod release kyaml [patch|minor|major] --doIt
 ```
 
 Note the version:
@@ -120,26 +108,27 @@ Note the version:
 versionKyaml=v0.10.20   # EDIT THIS!
 ```
 
-Undraft the release on the [kustomize repo release page],
-make sure the version number is what you expect.
+Undraft the release on the [kustomize repo release page]:
+* Make sure the version number is what you expect.
+* Remove references to commits that aren't relevant to end users of this module (e.g. test commits, refactors).
+* Make sure each commit left in the release notes includes a PR reference.
 
 
 ## Release `cmd/config`
 
-```
-cd ../kustomize
-```
-
-Pin to the most recent kyaml.
+#### Pin to the most recent kyaml
 
 ```
 gorepomod pin kyaml --doIt
+go mod edit -require=sigs.k8s.io/kustomize/kyaml@$versionKyaml plugin/builtin/prefixsuffixtransformer/go.mod
+go mod edit -require=sigs.k8s.io/kustomize/kyaml@$versionKyaml plugin/builtin/replicacounttransformer/go.mod
+
 ```
 
 Create the PR:
 ```
 title="Pin to kyaml $versionKyaml"
-createBranch pinToKyaml
+createBranch pinToKyaml $title
 createPr
 ```
 
@@ -160,9 +149,12 @@ refreshMaster
 testKustomizeRepo
 ```
 
-Release it:
+While you're waiting for the tests, review the commit log. Based on the changes to be included in this release, decide whether a patch, minor or major version bump is needed: [semver review].
+
+#### Release it
+
 ```
-gorepomod release cmd/config --doIt
+gorepomod release cmd/config [patch|minor|major] --doIt
 ```
 
 Note the version:
@@ -170,8 +162,10 @@ Note the version:
 versionCmdConfig=v0.9.12 # EDIT THIS!
 ```
 
-Undraft the release on the [kustomize repo release page],
-make sure the version number is what you expect.
+Undraft the release on the [kustomize repo release page]:
+* Make sure the version number is what you expect.
+* Remove references to commits that aren't relevant to end users of this module (e.g. test commits, refactors).
+* Make sure each commit left in the release notes includes a PR reference.
 
 
 ## Release `api` 
@@ -179,7 +173,7 @@ make sure the version number is what you expect.
 This is the kustomize API, used by the kustomize CLI.
 
 
-Pin to the new cmd/config:
+#### Pin to the new cmd/config
 
 ```
 gorepomod pin cmd/config --doIt
@@ -188,7 +182,7 @@ gorepomod pin cmd/config --doIt
 Create the PR:
 ```
 title="Pin to cmd/config $versionCmdConfig"
-createBranch pinToCmdConfig
+createBranch pinToCmdConfig $title
 createPr
 ```
 
@@ -209,9 +203,12 @@ refreshMaster
 testKustomizeRepo
 ```
 
-Release it:
+While you're waiting for the tests, review the commit log. Based on the changes to be included in this release, decide whether a patch, minor or major version bump is needed: [semver review].
+
+#### Release it
+
 ```
-gorepomod release api --doIt
+gorepomod release api [patch|minor|major] --doIt
 ```
 
 Note the version:
@@ -219,13 +216,16 @@ Note the version:
 versionApi=v0.8.10 # EDIT THIS!
 ```
 
-Undraft the release on the [kustomize repo release page],
-make sure the version number is what you expect.
+Undraft the release on the [kustomize repo release page]:
+* Make sure the version number is what you expect.
+* Remove references to commits that aren't relevant to end users of this module (e.g. test commits, refactors).
+* Make sure each commit left in the release notes includes a PR reference.
 
 
 ## Release the kustomize CLI
 
-Pin to the new API:
+#### Pin to the new API
+
 ```
 gorepomod pin api --doIt
 ```
@@ -233,7 +233,7 @@ gorepomod pin api --doIt
 Create the PR:
 ```
 title="Pin to api $versionApi"
-createBranch pinToApi
+createBranch pinToApi $title
 createPr
 ```
 
@@ -254,12 +254,18 @@ refreshMaster
 testKustomizeRepo
 ```
 
-Release it:
+While you're waiting for the tests, review the commit log. Based on the changes to be included in this release, decide whether a patch, minor or major version bump is needed: [semver review].
+
+#### Release it
+
 ```
-gorepomod release kustomize --doIt
+gorepomod release kustomize [patch|minor|major] --doIt
 ```
 
-Undraft the release on the [kustomize repo release page].
+Undraft the release on the [kustomize repo release page]:
+* Make sure the version number is what you expect.
+* Remove references to commits that aren't relevant to end users of the CLI (e.g. test commits, refactors, changes that only surface in Go).
+* Make sure each commit left in the release notes includes a PR reference.
 
 ## Confirm the kustomize binary is correct
 
@@ -308,10 +314,31 @@ refreshMaster
 testKustomizeRepo
 ```
 
-### Publish Official Docker Image
+## Update example test target
+
+[Makefile]: https://github.com/kubernetes-sigs/kustomize/blob/master/Makefile
+
+Edit the `prow-presubmit-target` in the [Makefile]
+to test examples against your new release.
+
+```
+sed -i "" "s/LATEST_V4_RELEASE=.*/LATEST_V4_RELEASE=v4.3.0/" Makefile
+title="Test examples against latest release"
+createBranch updateProwExamplesTarget $title
+createPr
+```
+
+Wait for tests to pass, then merge the PR:
+```
+gh pr status  # rinse, repeat
+gh pr merge -m
+```
+
+
+## Publish Official Docker Image
 
 [k8s.io]: https://github.com/kubernetes/k8s.io
-[k8s-staging-kustomize]: https://pantheon.corp.google.com/gcr/images/k8s-staging-kustomize?project=k8s-staging-kustomize
+[k8s-staging-kustomize]: https://console.cloud.google.com/gcr/images/k8s-staging-kustomize?project=k8s-staging-kustomize
 
 Fork and clone the [k8s.io] repo.
 
@@ -326,13 +353,6 @@ project [k8s-staging-kustomize].
 Commit and push your changes. Then create a PR to [k8s.io] to promote
 new images. Assign the PR to @monopole and @Shell32-natsu.
 
-### Finally
-
-[Makefile]: https://github.com/kubernetes-sigs/kustomize/blob/master/Makefile
-
-Edit the `prow-presubmit-target` in the [Makefile]
-to test examples against your new release.
-
 ----
 
 ----
@@ -462,21 +482,6 @@ Set the version you want:
 major=0; minor=1; patch=0
 ```
 
-#### semver review
-
-Go's [semver]-compatible version tags take the form `v{major}.{minor}.{patch}`:
-
-| major | minor | patch |
-| :---:   | :---:  | :---: |
-| API change | enhancements | bug fixes |
-| manual update | maybe auto-update | auto-update encouraged |
-
- - If there are only bug fixes or refactors, increment `patch` from whatever it is now.
- - If there are new features, increment  `minor`.
- - If there's an API change (either the Go API or the CLI behavior
-   with respect to CLI arguments and flags), increment `major`.
-
-
 
 ### Create the release branch
 

releasing/helpers.sh

@@ -0,0 +1,32 @@
+#!/usr/bin/env bash
+
+function createBranch {
+  branch=$1
+  title=$2
+  echo "Making branch $branch : \"$title\""
+  git branch -D $branch  # delete if it exists
+  git checkout -b $branch
+  git commit -a -m "$title"
+  git push -f origin $branch
+}
+
+function createPr {
+  gh pr create --title "$title" --body "ALLOW_MODULE_SPAN" --base master
+}
+
+function refreshMaster {
+  git checkout master
+  git fetch upstream
+  git rebase upstream/master
+}
+
+function testKustomizeRepo {
+  make prow-presubmit-check >& /tmp/k.txt
+  local code=$?
+  if [ $code -ne 0 ]; then
+    echo "**** FAILURE ******************"
+    tail /tmp/k.txt
+  else
+    echo "LGTM"
+  fi
+}