Mark a release as stable when we announce it, and stop using cherry_pick_list.sh

docs/devel/releasing.md

@@ -170,39 +170,35 @@ and follow the instructions.
 
 ### Publishing binaries and release notes
 
+Only publish a beta release if it's a standalone pre-release (*not*
+vX.Y.Z-beta.0).  We create beta tags after we do official releases to
+maintain proper semantic versioning, but we don't publish these beta releases.
+
 The script you ran above will prompt you to take any remaining steps to push
 tars, and will also give you a template for the release notes.  Compose an
-email to the team with the template, and use `build/make-release-notes.sh`
-and/or `release-notes/release-notes.go` in
-[kubernetes/contrib](https://github.com/kubernetes/contrib) to make the release
-notes, (see #17444 for more info).
-
-- Alpha release:
-  - Figure out what the PR numbers for this release and last release are, and
-    get an api-token from GitHub (https://github.com/settings/tokens).  From a
-    clone of kubernetes/contrib at upstream/master,
-      go run release-notes/release-notes.go --last-release-pr=<number> --current-release-pr=<number> --api-token=<token>
-    Feel free to prune.
-- Beta release:
-  - Only publish a beta release if it's a standalone pre-release.  (We create
-    beta tags after we do official releases to maintain proper semantic
-    versioning, *we don't publish these beta releases*.)  Use
-    `./hack/cherry_pick_list.sh ${RELEASE_VERSION}` to get release notes for such a
-    release.
-- Official release:
-  - From your clone of upstream/master, run `./hack/cherry_pick_list.sh ${RELEASE_VERSION}`
-    to get the release notes for the patch release you just created. Feel free
-    to prune anything internal, but typically for patch releases we tend to
-    include everything in the release notes.
-  - If this is a first official release (vX.Y.0), look through the release
-    notes for all of the alpha releases since the last cycle, and include
-    anything important in release notes.
+email to the team with the template.  Figure out what the PR numbers for this
+release and last release are, and get an api-token from GitHub
+(https://github.com/settings/tokens).  From a clone of
+[kubernetes/contrib](https://github.com/kubernetes/contrib),
+
+```
+go run release-notes/release-notes.go --last-release-pr=<number> --current-release-pr=<number> --api-token=<token> --base=<release-branch>
+```
+
+where `<release-branch>` is `master` for alpha releases and `release-X.Y` for beta and official releases.
+
+**If this is a first official release (vX.Y.0)**, look through the release
+notes for all of the alpha releases since the last cycle, and include anything
+important in release notes.
+
+Feel free to edit the notes, (e.g. cherry picks should generally just have the
+same title as the original PR).
 
 Send the email out, letting people know these are the draft release notes.  If
 they want to change anything, they should update the appropriate PRs with the
 `release-note` label.
 
-When we're ready to announce the release, [create a GitHub
+When you're ready to announce the release, [create a GitHub
 release](https://github.com/kubernetes/kubernetes/releases/new):
 
 1. pick the appropriate tag;
@@ -216,6 +212,10 @@ console.developers.google.com/storage/browser/kubernetes-release/release/),
    notes draft), and attach it to the release; and
 1. publish!
 
+Finally, from a clone of upstream/master, *make sure* you still have
+`RELEASE_VERSION` set correctly, and run `./build/mark-stable-release.sh
+${RELEASE_VERSION}`.
+
 ## Injecting Version into Binaries
 
 *Please note that this information may be out of date.  The scripts are the

hack/cherry_pick_list.sh

-#!/bin/bash
-
-# Copyright 2015 The Kubernetes Authors All rights reserved.
-#
-# Licensed under the Apache License, Version 2.0 (the "License");
-# you may not use this file except in compliance with the License.
-# You may obtain a copy of the License at
-#
-#     http://www.apache.org/licenses/LICENSE-2.0
-#
-# Unless required by applicable law or agreed to in writing, software
-# distributed under the License is distributed on an "AS IS" BASIS,
-# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-# See the License for the specific language governing permissions and
-# limitations under the License.
-
-# List cherry picks sitting on a release branch that AREN'T YET part
-# of a release. Used when constructing a release.
-
-set -o errexit
-set -o nounset
-set -o pipefail
-
-declare -r KUBE_ROOT="$(dirname "${BASH_SOURCE}")/.."
-
-if [[ "$#" -ne 1 ]]; then
-  echo "${0} <remote branch>: list all automated cherry picks on <remote release branch> since last release."
-  echo "  (assumes branch format of cherry_pick_pull.sh)"
-  echo ""
-  echo "Example:"
-  echo "  $0 upstream/release-1.0  # Lists all PRs on release-1.0 since list patch release."
-  exit 2
-fi
-
-declare -r BRANCH="$1"
-
-git remote update >/dev/null
-
-# First, the range specification: --abbrev=0 is saying to find the tag
-# relevant for the branch, so this essentially the git log all the way
-# back to the most recent tag on the release branch.
-#
-# The git log outputs something like:
-#  0f3cdb7234e2239707e4c3fc58f5f89552f41c65 Merge pull request #98765 from zaphod/automated-cherry-pick-of-#12345-#56789-#13579-upstream-release-1.0
-PULLS=( $(git log $(git describe --abbrev=0 "${BRANCH}").."${BRANCH}" -E --grep="Merge pull request \#[0-9]+ from .+/automated-cherry-pick-of-" --pretty=oneline |
-  awk '{ print $7 }' | sed -e 's/.*automated-cherry-pick-of-\(#[0-9]\{1,\}\)/\1/' -e 's/\(#[0-9]\{1,\}\)-[^#].*/\1/' -e 's/-/\
-/g' | sed 's/^#//g') )
-
-${KUBE_ROOT}/hack/lookup_pull.py "${PULLS[@]}"