<!-- **Note:** When your KEP is complete, all of these comment blocks should be removed. To get started with this template: - [ ] **Fill out this file as best you can.** At minimum, you should fill in the "Summary" and "Motivation" sections. These should be easy if you've preflighted the idea of the KEP with the appropriate SIG(s). - [ ] **Merge early and iterate.** Avoid getting hung up on specific details and instead aim to get the goals of the KEP clarified and merged quickly. The best way to do this is to just start with the high-level sections and fill out details incrementally in subsequent PRs. Just because a KEP is merged does not mean it is complete or approved. Any KEP marked as `provisional` is a working document and subject to change. You can denote sections that are under active debate as follows: ``` <<[UNRESOLVED optional short context or usernames ]>> Stuff that is being argued. <<[/UNRESOLVED]>> ``` When editing KEPS, aim for tightly-scoped, single-topic PRs to keep discussions focused. If you disagree with what is already in a document, open a new PR with suggested changes. One KEP corresponds to one "feature" or "enhancement" for its whole lifecycle. You do not need a new KEP to move from beta to GA, for example. If new details emerge that belong in the KEP, edit the KEP. Once a feature has become "implemented", major changes should get new KEPs. The canonical place for the latest set of instructions (and the likely source of this file) is [here](/keps/NNNN-kep-template/README.md). **Note:** Any PRs to move a KEP to `implementable`, or significant changes once it is marked `implementable`, must be approved by each of the KEP approvers. If none of those approvers are still appropriate, then changes to that list should be approved by the remaining approvers and/or the owning SIG (or SIG Architecture for cross-cutting KEPs). --> # KEP-2572: Defining the Kubernetes Release Cadence <!-- toc --> - [Release Signoff Checklist](#release-signoff-checklist) - [Summary](#summary) - [Motivation](#motivation) - [Goals](#goals) - [Enhance determinism](#enhance-determinism) - [Reduce risk](#reduce-risk) - [Collecting data](#collecting-data) - [Creating a policy](#creating-a-policy) - [Non-Goals](#non-goals) - [Long-term support (LTS) releases](#long-term-support-lts-releases) - [Changing enhancements graduation](#changing-enhancements-graduation) - [Architecture changes](#architecture-changes) - [Modifying SIG Architecture policies](#modifying-sig-architecture-policies) - [Accelerated release cycles](#accelerated-release-cycles) - [Establishing maintenance/stability releases](#establishing-maintenancestability-releases) - [Determining an upper bound for Release Team shadows](#determining-an-upper-bound-for-release-team-shadows) - [Proposal](#proposal) - [User Stories](#user-stories) - [End User](#end-user) - [Distributors and downstream projects](#distributors-and-downstream-projects) - [Contributors](#contributors) - [SIG Release members](#sig-release-members) - [Risks and Mitigations](#risks-and-mitigations) - [Concentrating risk](#concentrating-risk) - [Attention to tests](#attention-to-tests) - [Attention to dependencies](#attention-to-dependencies) - [Design Details](#design-details) - [Schedule Policy](#schedule-policy) - [Implementation History](#implementation-history) - [Leads meeting feedback session](#leads-meeting-feedback-session) - [Drawbacks](#drawbacks) - [Alternatives](#alternatives) <!-- /toc --> ## Release Signoff Checklist <!-- **ACTION REQUIRED:** In order to merge code into a release, there must be an issue in [kubernetes/enhancements] referencing this KEP and targeting a release milestone **before the [Enhancement Freeze](https://git.k8s.io/sig-release/releases) of the targeted release**. For enhancements that make changes to code or processes/procedures in core Kubernetes—i.e., [kubernetes/kubernetes], we require the following Release Signoff checklist to be completed. Check these off as they are completed for the Release Team to track. These checklist items _must_ be updated for the enhancement to be released. --> Items marked with (R) are required *prior to targeting to a milestone / release*. - [ ] (R) Enhancement issue in release milestone, which links to KEP dir in [kubernetes/enhancements] (not the initial KEP PR) - [ ] (R) KEP approvers have approved the KEP status as `implementable` - [ ] (R) Design details are appropriately documented - [ ] (R) Test plan is in place, giving consideration to SIG Architecture and SIG Testing input (including test refactors) - [ ] (R) Graduation criteria is in place - [ ] (R) Production readiness review completed - [ ] (R) Production readiness review approved - [ ] "Implementation History" section is up-to-date for milestone - [ ] User-facing documentation has been created in [kubernetes/website], for publication to [kubernetes.io] - [ ] Supporting documentation—e.g., additional design documents, links to mailing list discussions/SIG meetings, relevant PRs/issues, release notes <!-- **Note:** This checklist is iterative and should be reviewed and updated every time this enhancement is being considered for a milestone. --> [kubernetes.io]: https://kubernetes.io/ [kubernetes/enhancements]: https://git.k8s.io/enhancements [kubernetes/kubernetes]: https://git.k8s.io/kubernetes [kubernetes/website]: https://git.k8s.io/website ## Summary With this KEP, SIG Release proposes to change the current Kubernetes release cadence from 4 down to 3 releases per year. ## Motivation Discussions around changing the release cadence for Kubernetes, which currently releases 4 times per year, are ongoing in the community. The extended release schedule for 1.19 resulted in only three minor Kubernetes releases for 2020. As a result, SIG Release received several questions across a variety of platforms and communication channels about whether the project intends to only have three minor releases/year. ### Goals #### Enhance determinism With the current release cadence we already achieve a deterministic schedule for every year. The goal of this KEP is to increase this even further by providing a lightweight policy around creating the release schedule. Going down to 3 releases provides additional room for triage, development, and explicit breaks, which should result in better overall planning and more predictability. #### Reduce risk With higher predictability we can reduce the overall risk of changing the release schedule. The planning overhead of SIG Release gets reduced, while users of Kubernetes gain more time to adapt to the latest release. The current Kubernetes release cadence is so fast that most organizations cannot keep up with regularly making a minor version update every 3 months or going out of security support in a year. While releasing more frequently theoretically reduces the churn and risk of each release, this is only true if end users are actually able to apply the upgrades. #### Collecting data After this KEP is in place, SIG Release will follow up with a survey to collect feedback about the new release cadence. #### Creating a policy The outcome of this KEP is a policy for creating release schedules for Kubernetes. This allows the release team, as well as users, to follow a set of simple rules when it comes to knowing when and how Kubernetes releases will be scheduled. ### Non-Goals #### Long-term support (LTS) releases The LTS Working Group was [disbanded](https://github.com/kubernetes/community/pull/5240) on October 20, 2020. The outcome of their conversations was the proposal which established a [yearly support period][/keps/sig-release/1498-kubernetes-yearly-support-period/README.md] for minor releases of the project. While we may revisit the idea in the future, for now we trust the 2+ years of thoughtful deliberation by the working group enough to conclude that the project is not currently in a place to support long-term support releases. #### Changing enhancements graduation This KEP will not change the way that enhancements are being graduated. It's the responsibility of SIGs to keep track of their enhancements and graduate them in the provided constraints of SIG Architecture. The new release schedule will add room for only a few more weeks of development. SIGs should focus on using those additional weeks to enhance documentation and testing (stability)—not on adding more features. These decisions are not part of any SIG Release planning and will therefore be considered out of scope. #### Architecture changes Changing any architecture of Kubernetes—for example, decoupling its core components from the k/k repository—is outside the scope of this KEP. #### Modifying SIG Architecture policies Any policy change made by SIG Architecture is out of scope of this KEP. This non-goal corresponds partially to the [Changing enhancements graduation](#changing-enhancements-graduation) section. #### Accelerated release cycles The intent of this proposal is to create more opportunities to provide a high-value experience for Kubernetes consumers. The Kubernetes community faces a reasonable amount of tech debt across infrastructure, testing, policy, and documentation. This KEP proposes that we spend more time paying down that debt. SIG Release currently produces releases at the following cadence: - patch releases (`x.y.Z`): [monthly][https://git.k8s.io/sig-release/releases/patch-releases.md] - minor releases (`x.Y.z`): [every four months][https://git.k8s.io/sig-release/release-engineering/versioning.md] - pre-releases (`x.y.0-(alpha|beta|rc).N`): every 1-3 weeks during active development cycles ([example](https://git.k8s.io/sig-release/releases/release-1.21/README.md#timeline)) At the time of writing, SIG Release considers these to be reasonable cadences for patch and pre-releases. If you'd like to provide suggestions on longer-term improvements that could potentially accelerate production of releases, please join the discussion [here](https://github.com/kubernetes/sig-release/discussions/1495). #### Establishing maintenance/stability releases Establishing a shorter maintenance/stability release at the end of the year has been casually discussed at several points in the project, with the most recent (at the time of writing) occurrence being [here](https://github.com/kubernetes/sig-release/issues/809). Nothing compelling has emerged from previous conversations to give cause to establish maintenance/stability releases. Fixing bugs, stabilizing components, adding/deflaking tests, improving documentation, and graduating features are activities that can and should happen in a reasonably consistent manner throughout the year. #### Determining an upper bound for Release Team shadows It was noted that fewer releases for the year would lead to fewer opportunities to participate on the Release Team. This will be discussed and addressed in https://github.com/kubernetes/sig-release/issues/1494. ## Proposal ### User Stories Kubernetes releases are made by real people. The technical aspects—for example, the release automation—reflects only a tiny part of the complete cycle. This means we will mainly focus on the human aspects and their corresponding roles when deciding to move to a 3-releases-per-year cadence. #### End User Most companies are facing issues upgrading Kubernetes 4 times a year. Providing only 3 releases per year will relax this situation. #### Distributors and downstream projects Downstream projects assemble their solution from different projects. Having fewer upgrades helps them to reduce complexity. For example, cloud providers will gain more room for upgrading their infrastructure. #### Contributors With a lower release cadence, contributors will gain more time for project enhancements, feature development, planning, and testing. It will provide more room for maintaining their mental health and prepare for events like KubeCon. Through this proposal SIG Release's aim is to give contributors more flexibility to decide how to invest their time. It is explicitly *not* to push contributors in doing more. #### SIG Release members By applying a cadence of 3 releases per year, SIG Release members will gain a reduced management overhead. There are also only 3 patch releases to maintain, which right now can overlap up to 4. SIG Release will gain more time to ensure a seamless transition from the previous release team to the next one. It is also possible to include more shadows if the role leads conclude that this is appropriate. ### Risks and Mitigations #### Concentrating risk In theory a reduced release cadence will cause more changes for every release. This means that there will be an increased risk, which would usually be split up into 4 dedicated milestones rather than 3. SIG Release cannot mitigate this risk directly, but is able to track and influence it during each release cycle. It's the responsibility of SIG Release, together with SIG Testing and SIG Architecture, to identify new gaps and issues in the release cadence and mitigate them on a case-by-case basis. #### Attention to tests This KEP does not propose any change to the release cycle itself and assumes that the same periods for Code and Test Freeze. Assuming that, there is an increased risk for flakes and test failures. It will be the responsibility of SIG Release to mitigate this, together with the CI signal role. If we speak about an overall release cycle enhancement of 3-4 weeks, then we believe that SIG Release is able to mitigate this risk over multiple releases. #### Attention to dependencies Having fewer releases will introduce the risk of missing dependencies—for example, Golang upgrades. This has to be mitigated on a case-by-case basis, in the same way as it is being done right now. ## Design Details ### Schedule Policy The exact details of the release schedule are created by the team leads before the actual cycle begins. SIG Release only provides a lightweight policy, which is defined as: 1. The first Kubernetes release of a year should start at the second or third week of January to provide people more room after coming back from the Christmas holidays. 2. The last Kubernetes release of a year should be finished by the middle of December. 3. A Kubernetes release cycle has a length of of ~15 weeks. 4. Events like KubeCon will be considered as blocked from development or decision-making. SIG Release will also consider the week before and after the event in the same way. 5. An explicit break of at least two weeks between each release cycle will be enforced. This does not mean that zero development can happen during that time. Rather, SIG Release will use this time to do the release retrospective and plan for the next cycle. ## Implementation History <!-- Major milestones in the lifecycle of a KEP should be tracked in this section. Major milestones might include: - the `Summary` and `Motivation` sections being merged, signaling SIG acceptance - the `Proposal` section being merged, signaling agreement on a proposed design - the date implementation started - the first Kubernetes release where an initial version of the KEP was available - the version of Kubernetes where the KEP graduated to general availability - when the KEP was retired or superseded --> ### Leads meeting feedback session Already captured above, but you can find meeting notes [here](https://docs.google.com/document/d/1Jio9rEtYxlBbntF8mRGmj6Q1JAdzZ9fTDo3ru1HK_LI/edit#bookmark=id.val5alfdahlr). ## Drawbacks The main drawbacks of this KEP have been covered in the [Risks and Mitigations](#risks-and-mitigations) section. ## Alternatives The alternative appraoches have been discussed in the [Non-goals](#non-goals) section.