Merge pull request #17446 from ihmccreery/no-more-latest

Auto commit by PR queue bot

docs/devel/releasing.md

@@ -134,123 +134,31 @@ cd kubernetes
 
 or `git checkout upstream/master` from an existing repo.
 
-#### Cutting an alpha release (`vX.Y.0-alpha.W`)
+Decide what version you're cutting and export it:
 
-Figure out what version you're cutting, and
+- alpha release: `export VER="vX.Y.0-alpha.W"`;
+- beta release: `export VER="vX.Y.Z-beta.W"`;
+- official release: `export VER="vX.Y.Z"`;
+- new release series: `export VER="vX.Y"`.
 
-```console
+Then, run
-export VER="vX.Y.0-alpha.W"
-```
-
-then, run
 
 ```console
 ./release/cut-official-release.sh "${VER}" "${GITHASH}"
 ```
 
-This will do a dry run of:
+This will do a dry run of the release.  It will give you instructions at the
-
+end for `pushd`ing into the dry-run directory and having a look around.
-1. mark the `vX.Y.0-alpha.W` tag at the given git hash;
+`pushd` into the directory and make sure everythig looks as you expect:
-1. prompt you to do the remainder of the work, including building the
-   appropriate binaries and pushing them to the appropriate places.
-
-If you're satisfied with the result, run
 
 ```console
-./release/cut-official-release.sh "${VER}" "${GITHASH}" --no-dry-run
+git log "${VER}"  # do you see the commit you expect?
+make release
+./cluster/kubectl.sh version -c
 ```
 
-and follow the instructions.
+If you're satisfied with the result of the script, go back to `upstream/master`
-
+run
-#### Cutting an beta release (`vX.Y.Z-beta.W`)
-
-Figure out what version you're cutting, and
-
-```console
-export VER="vX.Y.Z-beta.W"
-```
-
-then, run
-
-```console
-./release/cut-official-release.sh "${VER}" "${GITHASH}"
-```
-
-This will do a dry run of:
-
-1. do a series of commits on the release branch for `vX.Y.Z-beta.W`;
-1. mark the `vX.Y.Z-beta.W` tag at the beta version commit;
-1. prompt you to do the remainder of the work, including building the
-   appropriate binaries and pushing them to the appropriate places.
-
-If you're satisfied with the result, run
-
-```console
-./release/cut-official-release.sh "${VER}" "${GITHASH}" --no-dry-run
-```
-
-and follow the instructions.
-
-#### Cutting an official release (`vX.Y.Z`)
-
-Figure out what version you're cutting, and
-
-```console
-export VER="vX.Y.Z"
-```
-
-then, run
-
-```console
-./release/cut-official-release.sh "${VER}" "${GITHASH}"
-```
-
-This will do a dry run of:
-
-1. do a series of commits on the branch for `vX.Y.Z`;
-1. mark the `vX.Y.Z` tag at the release version commit;
-1. do a series of commits on the branch for `vX.Y.(Z+1)-beta.0` on top of the
-   previous commits;
-1. mark the `vX.Y.(Z+1)-beta.0` tag at the beta version commit;
-1. prompt you to do the remainder of the work, including building the
-   appropriate binaries and pushing them to the appropriate places.
-
-If you're satisfied with the result, run
-
-```console
-./release/cut-official-release.sh "${VER}" "${GITHASH}" --no-dry-run
-```
-
-and follow the instructions.
-
-#### Branching a new release series (`vX.Y`)
-
-Once again, **this is a big deal!**  If you're reading this doc for the first
-time, you probably shouldn't be doing this release, and should talk to someone
-on the release team.
-
-Figure out what series you're cutting, and
-
-```console
-export VER="vX.Y"
-```
-
-then, run
-
-```console
-./release/cut-official-release.sh "${VER}" "${GITHASH}"
-```
-
-This will do a dry run of:
-
-1. mark the `vX.(Y+1).0-alpha.0` tag at the given git hash on `master`;
-1. fork a new branch `release-X.Y` off of `master` at the given git hash;
-1. do a series of commits on the branch for `vX.Y.0-beta.0`;
-1. mark the `vX.Y.0-beta.0` tag at the beta version commit;
-1. prompt you to do the remainder of the work, including building the
-   appropriate binaries and pushing them to the appropriate places.
-
-If you're satisfied with the result, run
 
 ```console
 ./release/cut-official-release.sh "${VER}" "${GITHASH}" --no-dry-run
@@ -260,8 +168,50 @@ and follow the instructions.
 
 ### Publishing binaries and release notes
 
-The script you ran above will prompt you to take any remaining steps, including
+The script you ran above will prompt you to take any remaining steps to push
-publishing binaries and release notes.
+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 ${VER}` to get release notes for such a
+    release.
+- Official release:
+  - From your clone of upstream/master, run `./hack/cherry_pick_list.sh ${VER}`
+    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.
+
+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
+release](https://github.com/kubernetes/kubernetes/releases/new):
+
+1. pick the appropriate tag;
+1. check "This is a pre-release" if it's an alpha or beta release;
+1. fill in the release title from the draft;
+1. re-run the appropriate release notes tool(s) to pick up any changes people
+   have made;
+1. find the appropriate `kubernetes.tar.gz` in GCS, download it, double check
+   the hash (compare to what you had in the release notes draft), and attach it
+   to the release; and
+1. publish!
 
 ## Injecting Version into Binaries
 

release/build-official-release.sh

@@ -98,18 +98,13 @@ instructions elsewhere):
 
   1) pushd ${KUBE_BUILD_DIR}; build/push-official-release.sh ${KUBE_RELEASE_VERSION}
 
-  2) Go to https://github.com/GoogleCloudPlatform/kubernetes/releases
+  2) Release notes draft, to be published when the release is announced:
-     and create a new release with the ${KUBE_RELEASE_VERSION} tag.
 
-     a) Mark it as a pre-release (someone on the GKE team will mark it as an
+     a) Title:
-     official release when it's being rolled out, but should not be considered
-     stable prior to that).
-
-     b) Title it:
 
        Release ${KUBE_RELEASE_VERSION}
 
-     c) Use this template for the description:
+     b) Template for the description:
 
 ## [Documentation](http://releases.k8s.io/${RELEASE_BRANCH}/docs/README.md)
 ## [Examples](http://releases.k8s.io/${RELEASE_BRANCH}/examples)
@@ -124,10 +119,9 @@ binary | hash alg | hash
 
      We'll fill in the release notes in the next stage.
 
-  3) Upload the ${KUBE_BUILD_DIR}/kubernetes.tar.gz to GitHub
+  4) Ensure all the binaries are in place on GCS before cleaning, (you might
+  want to wait until the release is announced and published on GitHub, too).
 
-  4) Ensure all the binaries are in place on GitHub and GCS before cleaning.
+  5) make clean; popd; rm -rf ${KUBE_BUILD_DIR}
-
-  5) (make clean; popd; rm -rf ${KUBE_BUILD_DIR})
 
 EOM

release/cut-official-release.sh

@@ -93,7 +93,7 @@ function main() {
   local -r release_umask=${release_umask:-022}
   umask "${release_umask}"
 
-  local -r github="git@github.com:kubernetes/kubernetes.git"
+  local -r github="https://github.com/kubernetes/kubernetes.git"
   declare -r DIR=$(mktemp -d "/tmp/kubernetes-${release_type}-release-${new_version}-XXXXXXX")
 
   # Start a tmp file that will hold instructions for the user.
@@ -148,8 +148,8 @@ EOM
     git-push ${release_branch}
   elif [[ "${release_type}" == 'official' ]]; then
     local -r release_branch="release-${version_major}.${version_minor}"
-    local -r beta_version="v${version_major}.${version_minor}.$((${version_patch}+1))-beta"
+    local -r beta_version="v${version_major}.${version_minor}.$((${version_patch}+1))-beta.0"
-    local -r ancestor="${new_version}-beta"
+    local -r ancestor="${new_version}-beta.0"
 
     git checkout "${release_branch}"
     verify-at-git-commit "${git_commit}"
@@ -162,7 +162,7 @@ EOM
   else # [[ "${release_type}" == 'series' ]]
     local -r release_branch="release-${version_major}.${version_minor}"
     local -r alpha_version="v${version_major}.$((${version_minor}+1)).0-alpha.0"
-    local -r beta_version="v${version_major}.${version_minor}.0-beta"
+    local -r beta_version="v${version_major}.${version_minor}.0-beta.0"
     # NOTE: We check the second alpha version, ...-alpha.1, because ...-alpha.0
     # is the branch point for the previous release cycle, so could provide a
     # false positive if we accidentally try to release off of the old release
@@ -215,15 +215,9 @@ function alpha-release() {
   git-push "${alpha_version}"
 
   cat >> "${INSTRUCTIONS}" <<- EOM
-- Finish the ${alpha_version} release build:
+- Finish the ${alpha_version} release build: from this directory (clone of
-  - From this directory (clone of upstream/master),
+  upstream/master),
     ./release/build-official-release.sh ${alpha_version}
-  - Prep release notes:
-    - 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.
 EOM
 }
 
@@ -238,11 +232,9 @@ function beta-release() {
   git tag -a -m "Kubernetes pre-release ${beta_version}" "${beta_version}"
   git-push "${beta_version}"
 
-  # NOTE: We currently don't publish beta release notes, since they'll go out
-  # with the official release, so we don't prompt for compiling them here.
   cat >> "${INSTRUCTIONS}" <<- EOM
-- Finish the ${beta_version} release build:
+- Finish the ${beta_version} release build: from this directory (clone of
-  - From this directory (clone of upstream/master),
+  upstream/master),
     ./release/build-official-release.sh ${beta_version}
 EOM
 }
@@ -259,18 +251,9 @@ function official-release() {
   git-push "${official_version}"
 
   cat >> "${INSTRUCTIONS}" <<- EOM
-- Finish the ${official_version} release build:
+- Finish the ${official_version} release build: from this directory (clone of
-  - From this directory (clone of upstream/master),
+  upstream/master),
     ./release/build-official-release.sh ${official_version}
-  - Prep release notes:
-    - From this directory (clone of upstream/master), run
-        ./hack/cherry_pick_list.sh ${official_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), scan through the release
-      notes for all of the alpha releases since the last cycle, and include
-      anything important in release notes.
 EOM
 }