diff --git a/docs/design/versioning.md b/docs/design/versioning.md index a189d0cfa49..7b63059ce9f 100644 --- a/docs/design/versioning.md +++ b/docs/design/versioning.md @@ -43,9 +43,9 @@ Legend: ### Minor version scheme and timeline * Kube X.Y.0-alpha.W, W > 0: Alpha releases are released roughly every two weeks directly from the master branch. No cherrypick releases. If there is a critical bugfix, a new release from master can be created ahead of schedule. -* Kube X.Y.Z-beta: When master is feature-complete for Kube X.Y, we will cut the release-X.Y branch 2 weeks prior to the desired X.Y.0 date and cherrypick only PRs essential to X.Y. This cut will be marked as X.Y.0-beta, and master will be revved to X.Y+1.0-alpha.0. -* Kube X.Y.0: Final release, cut from the release-X.Y branch cut two weeks prior. X.Y.1-beta will be tagged at the same commit on the same branch. X.Y.0 occur 3 to 4 months after X.Y-1.0. -* Kube X.Y.Z, Z > 0: [Patch releases](#patches) are released as we cherrypick commits into the release-X.Y branch, (which is at X.Y.Z-beta,) as needed. X.Y.Z is cut straight from the release-X.Y branch, and X.Y.Z+1-beta is tagged on the same commit. +* Kube X.Y.Z-beta.W: When master is feature-complete for Kube X.Y, we will cut the release-X.Y branch 2 weeks prior to the desired X.Y.0 date and cherrypick only PRs essential to X.Y. This cut will be marked as X.Y.0-beta.0, and master will be revved to X.Y+1.0-alpha.0. If we're not satisfied with X.Y.0-beta.0, we'll release other beta releases, (X.Y.0-beta.W | W > 0) as necessary. +* Kube X.Y.0: Final release, cut from the release-X.Y branch cut two weeks prior. X.Y.1-beta.0 will be tagged at the same commit on the same branch. X.Y.0 occur 3 to 4 months after X.Y-1.0. +* Kube X.Y.Z, Z > 0: [Patch releases](#patches) are released as we cherrypick commits into the release-X.Y branch, (which is at X.Y.Z-beta.W,) as needed. X.Y.Z is cut straight from the release-X.Y branch, and X.Y.Z+1-beta.0 is tagged on the same commit. ### Major version timeline @@ -53,7 +53,7 @@ There is no mandated timeline for major versions. They only occur when we need t ### CI version scheme -* Continuous integration versions also exist, and are versioned off of alpha and beta releases. X.Y.Z-alpha.W.C+aaaa is C commits after X.Y.Z-alpha.W, with an additional +aaaa build suffix added; X.Y.Z-beta.C+bbbb is C commits after X.Y.Z-beta, with an additional +bbbb build suffix added. Furthermore, builds that are built off of a dirty build tree, (with things in the tree that are not checked it,) it will be appended with -dirty. +* Continuous integration versions also exist, and are versioned off of alpha and beta releases. X.Y.Z-alpha.W.C+aaaa is C commits after X.Y.Z-alpha.W, with an additional +aaaa build suffix added; X.Y.Z-beta.W.C+bbbb is C commits after X.Y.Z-beta.W, with an additional +bbbb build suffix added. Furthermore, builds that are built off of a dirty build tree, (with things in the tree that are not checked it,) it will be appended with -dirty. ## Release versions as related to API versions diff --git a/docs/devel/releasing.md b/docs/devel/releasing.md index fad957b6229..f430b3a3958 100644 --- a/docs/devel/releasing.md +++ b/docs/devel/releasing.md @@ -56,14 +56,20 @@ from, and other prerequisites. * Alpha releases (`vX.Y.0-alpha.W`) are cut directly from `master`. * Alpha releases don't require anything besides green tests, (see below). -* Official releases (`vX.Y.Z`) are cut from their respective release branch, +* Beta releases (`vX.Y.Z-beta.W`) are cut from their respective release branch, `release-X.Y`. * Make sure all necessary cherry picks have been resolved. You should ensure that all outstanding cherry picks have been reviewed and merged and the branch validated on Jenkins. See [Cherry Picks](cherry-picks.md) for more information on how to manage cherry picks prior to cutting the release. + * Beta releases also require green tests, (see below). +* Official releases (`vX.Y.Z`) are cut from their respective release branch, + `release-X.Y`. + * Official releases should be similar or identical to their respective beta + releases, so have a look at the cherry picks that have been merged since + the beta release and question everything you find. * Official releases also require green tests, (see below). -* New release series are also cut direclty from `master`. +* New release series are also cut directly from `master`. * **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. diff --git a/release/cut-official-release.sh b/release/cut-official-release.sh index e396a51f83e..eed2fe31c4c 100755 --- a/release/cut-official-release.sh +++ b/release/cut-official-release.sh @@ -43,6 +43,7 @@ function main() { # Get and verify version info local -r alpha_version_regex="^v(0|[1-9][0-9]*)\\.(0|[1-9][0-9]*)\\.0-alpha\\.([1-9][0-9]*)$" + local -r beta_version_regex="^v(0|[1-9][0-9]*)\\.(0|[1-9][0-9]*)\\.(0|[1-9][0-9]*)-beta\\.([1-9][0-9]*)$" local -r official_version_regex="^v(0|[1-9][0-9]*)\\.(0|[1-9][0-9]*)\\.(0|[1-9][0-9]*)$" local -r series_version_regex="^v(0|[1-9][0-9]*)\\.(0|[1-9][0-9]*)$" if [[ "${new_version}" =~ $alpha_version_regex ]]; then @@ -50,6 +51,12 @@ function main() { local -r version_major="${BASH_REMATCH[1]}" local -r version_minor="${BASH_REMATCH[2]}" local -r version_alpha_rev="${BASH_REMATCH[3]}" + elif [[ "${new_version}" =~ $beta_version_regex ]]; then + local -r release_type='beta' + local -r version_major="${BASH_REMATCH[1]}" + local -r version_minor="${BASH_REMATCH[2]}" + local -r version_patch="${BASH_REMATCH[3]}" + local -r version_beta_rev="${BASH_REMATCH[4]}" elif [[ "${new_version}" =~ $official_version_regex ]]; then local -r release_type='official' local -r version_major="${BASH_REMATCH[1]}" @@ -114,11 +121,23 @@ EOM if [[ "${release_type}" == 'alpha' ]]; then local -r ancestor="v${version_major}.${version_minor}.0-alpha.$((${version_alpha_rev}-1))" + git checkout "${git_commit}" verify-at-git-commit "${git_commit}" verify-ancestor "${ancestor}" alpha-release "${new_version}" + elif [[ "${release_type}" == 'beta' ]]; then + local -r release_branch="release-${version_major}.${version_minor}" + local -r ancestor="v${version_major}.${version_minor}.${version_patch}-beta.$((${version_beta_rev}-1))" + + git checkout "${release_branch}" + verify-at-git-commit "${git_commit}" + verify-ancestor "${ancestor}" + + beta-release "${new_version}" + + 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" @@ -130,6 +149,8 @@ EOM official-release "${new_version}" beta-release "${beta_version}" + + git-push ${release_branch} 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" @@ -151,6 +172,7 @@ EOM versionize-docs-and-commit "${release_branch}" beta-release "${beta_version}" + git-push ${release_branch} fi @@ -208,9 +230,13 @@ function beta-release() { git tag -a -m "Kubernetes pre-release ${beta_version}" "${beta_version}" git-push "${beta_version}" - # NOTE: We currently don't build/release beta versions, since they're almost - # identical to the prior version, so we don't prompt for build or release - # here. + # 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} +EOM } function official-release() { @@ -245,9 +271,9 @@ function verify-at-git-commit() { echo "Verifying we are at ${git_commit}." if [[ $(current-git-commit) != ${git_commit} ]]; then cat <<- EOM -!!! We are not at commit ${git_commit}! (If you're cutting an official release, -that probably means your release branch isn't frozen, so the commit you want to -release isn't at HEAD of the release branch.)" +!!! We are not at commit ${git_commit}! (If you're cutting a beta or official +release, that probably means your release branch isn't frozen, so the commit +you want to release isn't at HEAD of the release branch.)" EOM exit 1 fi @@ -279,14 +305,14 @@ function rev-version-and-commit() { local -r version="${1}" local -r version_file="pkg/version/base.go" - local -r version_regex="^v(0|[1-9][0-9]*)\\.(0|[1-9][0-9]*)\\.(0|[1-9][0-9]*)(-beta)?$" + local -r version_regex="^v(0|[1-9][0-9]*)\\.(0|[1-9][0-9]*)\\.(0|[1-9][0-9]*)(-beta\\.(0|[1-9][0-9]*))?$" if [[ "${version}" =~ $version_regex ]]; then local -r version_major="${BASH_REMATCH[1]}" # We append a '+' to the minor version on a beta build per hack/lib/version.sh's logic. - if [[ "${BASH_REMATCH[4]}" == '-beta' ]]; then - local -r version_minor="${BASH_REMATCH[2]}+" - else + if [[ -z "${BASH_REMATCH[4]}" ]]; then local -r version_minor="${BASH_REMATCH[2]}" + else + local -r version_minor="${BASH_REMATCH[2]}+" fi else echo "!!! Something went wrong. Tried to rev version to invalid version; should not have gotten to this point."