Change:
# Kubernetes API and Release Versioning <ins> Reference: [Semantic Versioning](http://semver.org) </ins> Legend: <del> * **Kube X.Y.Z** refers to the version of Kubernetes that is released. This versions all components: apiserver, kubelet, kubectl, etc.  (**X** is the major version, **Y** is the minor version, and **Z** is the patch version.) </del> <ins> * **Kube X.Y.Z** refers to the version (git tag) of Kubernetes that is released. This versions all components: apiserver, kubelet, kubectl, etc.  (**X** is the major version, **Y** is the minor version, and **Z** is the patch version.) </ins> * **API vX[betaY]** refers to the version of the HTTP API. ## Release versioning ### Minor version scheme and timeline <del> * 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.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](#patch-releases) 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. </del> <ins> * Kube X.Y.0-alpha.W, W > 0 (Branch: master) * 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.W (Branch: release-X.Y) * 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 (Branch: release-X.Y) * 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 (Branch: release-X.Y) * [Patch releases](#patch-releases) 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 followup commit that updates pkg/version/base.go with the beta version. * Kube X.Y.Z, Z > 0 (Branch: release-X.Y.Z) * These are special and different in that the X.Y.Z tag is branched to isolate the emergency/critical fix from all other changes that have landed on the release branch since the previous tag * Cut release-X.Y.Z branch to hold the isolated patch release * Tag release-X.Y.Z branch + fixes with X.Y.(Z+1) * Branched [patch releases](#patch-releases) are rarely needed but used for emergency/critical fixes to the latest release * See [#19849](https://issues.k8s.io/19849) tracking the work that is needed for this kind of release to be possible. </ins> ### Major version timeline

Discussion:
This is a top-level/meta issue that may spawn sub-issues. The doc has been recently updated to cover a branching a branch scenario. This is a rare or unlikely occurrence (depending on the teams velocity/needs), but important to plan for nonetheless. Refer to that doc for more details. Any assumptions of a X.Y.Z format need to be dealt with in k8s tooling as well as GKE should we ever want/need to implement this.
It should also be noted that should we need to go this route, we will want to switch to a 4 part version number to avoid any ambiguity (and support hassles) of a mix of 3 and 4 part versions.
The best route here to avoid modifications to the semantic versioning scheme we are currently using for K8S, is to update the tooling to handle branching from a X.Y.Z tag, but maintain the 3-part version scheme. The doc will be updated with details.
Release tooling for branching and building complete in pending TODO list for a zero-day: branch of X.Y.Z (45 minutes) of new branch Do we need a complete set of test infrastructure here or can we define some subset for this purpose? Do we have any mechanisms for easily/quickly spinning up a set of testing infrastructure. Whether we do or not, what is the required setup time for something like this? and submit queue wait (up to N hours) test time for new branch + patch (N hours) the final release from new branch (45 minutes)
Thanks Internal to Google, the time from a PR to a built binary that could potentially be rolled out is I think a bit shorter than the TODO list you mentioned above. Would it make sense to start from e.g. a 1 hour PR-to-rollout target and see what we'd have to do to get there?
yes. For the sake of consistency the initial branch follows the current model of creating the tags and initial builds (and pushes). We could short-circuit that process to just branch and tag which would reduce the time significantly, closer to a few minutes. Then the actual release with a build and push will take around 45 minutes.

The more variable pieces are how much testing we want to do and if we want infrastructure set up, how long it will take to spin it up and push a PR through it (submit queue -jenkins' test suites) This is all potentially variable depending on what the fix itself is, though I suspect we probably don't want to be figuring that out on the fly during the event itself and would rather just have our usual, complete infrastructure ready to go. We can hammer this out in more detail in a PRD but I'd like to get a sense of a realistic target and skeleton plan here. Testing is the big question mark here. Thoughts ?
it looks like doesn't have a reviewer. Do we expect to get it submitted soon? Since it's in a different repository, this issue doesn't seem intrinsically tied to the 1.3 milestone, other than that we wanted visibility around getting a fix for this issue. Does it still belong in the 1.3 milestone?
Correct, it is not directly tied to 1.3. Removed.
I don't understand the difference between these releases and normal patch releases. It sounds like these are for emergency releases but I don't understand why they don't get released like normal x.y.z releases. xref
Standard x.y.z releases contain cumulative patches on that branch. The emergency branches are branched from a specific x.y.z release/tag.
understood, got it, that makes sense. Just a little head spiny trying to read I think we need to create better naming and categories for overall. post.
/sig release
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. Prevent issues from auto-closing with an comment. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or .

/lifecycle rotten /remove-lifecycle stale
Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . Send feedback to sig-testing, kubernetes/test-infra and/or . /close