github/kubernetes
1
0
Fork 0
mirror of https://github.com/k3s-io/kubernetes.git synced 2025-07-24 12:15:52 +00:00
Code Issues Projects Releases Wiki Activity

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

Browse Source 
Auto commit by PR queue bot
This commit is contained in:
k8s-merge-robot 2015-11-24 03:41:32 -08:00
commit 8500a0fe96
3 changed files with 77 additions and 150 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

166
docs/devel/releasing.md
View File

@ -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
export VER="vX.Y.0-alpha.W"
```
then, run
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
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.
`pushd` into the directory and make sure everythig looks as you expect:
```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.
#### 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
If you're satisfied with the result of the script, go back to `upstream/master`
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
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=<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

18
release/build-official-release.sh
View File

@ -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 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

43
release/cut-official-release.sh
View File

@ -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 ancestor="${new_version}-beta"
local -r beta_version="v${version_major}.${version_minor}.$((${version_patch}+1))-beta.0"
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:
- 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=<number> --current-release-pr=<number> --api-token=<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
}