From 2bc124d51089bff1ecabfe2867dc7ebd50a49e54 Mon Sep 17 00:00:00 2001 From: Isaac Hollander McCreery Date: Wed, 18 Nov 2015 09:50:56 -0800 Subject: [PATCH] Defer release notes to announcement of release, and move instructions for release notes back into docs and away from scripts --- docs/devel/releasing.md | 165 ++++++++++-------------------- release/build-official-release.sh | 18 ++-- release/cut-official-release.sh | 35 ++----- 3 files changed, 68 insertions(+), 150 deletions(-) diff --git a/docs/devel/releasing.md b/docs/devel/releasing.md index 01f185bd9cd93..4805481f9ae14 100644 --- a/docs/devel/releasing.md +++ b/docs/devel/releasing.md @@ -134,123 +134,22 @@ 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 -export VER="vX.Y.0-alpha.W" -``` - -then, run - -```console -./release/cut-official-release.sh "${VER}" "${GITHASH}" -``` - -This will do a dry run of: - -1. mark the `vX.Y.0-alpha.W` tag at the given git hash; -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 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 +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 +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. If +you're satisfied with the result, run ```console ./release/cut-official-release.sh "${VER}" "${GITHASH}" --no-dry-run @@ -260,8 +159,50 @@ and follow the instructions. ### Publishing binaries and release notes -The script you ran above will prompt you to take any remaining steps, including -publishing binaries and release notes. +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= --current-release-pr= --api-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 diff --git a/release/build-official-release.sh b/release/build-official-release.sh index 0cea3db703cf0..2e7e6e559f586 100755 --- a/release/build-official-release.sh +++ b/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 - and create a new release with the ${KUBE_RELEASE_VERSION} tag. + 2) Release notes draft, to be published when the release is announced: - a) Mark it as a pre-release (someone on the GKE team will mark it as an - official release when it's being rolled out, but should not be considered - stable prior to that). - - b) Title it: + a) Title: 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 GitHub and GCS before cleaning. + 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). - 5) (make clean; popd; rm -rf ${KUBE_BUILD_DIR}) + 5) make clean; popd; rm -rf ${KUBE_BUILD_DIR} EOM diff --git a/release/cut-official-release.sh b/release/cut-official-release.sh index 50770de73ece9..d477367f6941d 100755 --- a/release/cut-official-release.sh +++ b/release/cut-official-release.sh @@ -215,15 +215,9 @@ function alpha-release() { git-push "${alpha_version}" cat >> "${INSTRUCTIONS}" <<- EOM -- Finish the ${alpha_version} release build: - - From this directory (clone of 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= --current-release-pr= --api-token= - Feel free to prune. +- Finish the ${alpha_version} release build: from this directory (clone of + upstream/master), + ./release/build-official-release.sh ${alpha_version} EOM } @@ -238,12 +232,10 @@ 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: - - From this directory (clone of upstream/master), - ./release/build-official-release.sh ${beta_version} +- Finish the ${beta_version} release build: from this directory (clone of + 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: - - From this directory (clone of 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. +- Finish the ${official_version} release build: from this directory (clone of + upstream/master), + ./release/build-official-release.sh ${official_version} EOM }