Versioned beta releases

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.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 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.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,) 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, 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
 

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.

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
+  # NOTE: We currently don't publish beta release notes, since they'll go out
-  # identical to the prior version, so we don't prompt for build or release
+  # with the official release, so we don't prompt for compiling them here.
-  # 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,
+!!! We are not at commit ${git_commit}! (If you're cutting a beta or official
-that probably means your release branch isn't frozen, so the commit you want to
+release, that probably means your release branch isn't frozen, so the commit
-release isn't at HEAD of the release branch.)"
+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
+    if [[ -z "${BASH_REMATCH[4]}" ]]; then
-      local -r version_minor="${BASH_REMATCH[2]}+"
-    else
       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."