From 9f501d0f73f5da5489991c2c182b07fc4762e760 Mon Sep 17 00:00:00 2001 From: Jeremy Date: Mon, 12 Jul 2021 08:56:43 -0600 Subject: [PATCH 1/7] Adding a blog to discuss release cadence change --- .../index.md | 84 +++++++++++++++++++ 1 file changed, 84 insertions(+) create mode 100644 content/en/blog/_posts/2021-07-12-Kubernetes-Release-Cadence/index.md diff --git a/content/en/blog/_posts/2021-07-12-Kubernetes-Release-Cadence/index.md b/content/en/blog/_posts/2021-07-12-Kubernetes-Release-Cadence/index.md new file mode 100644 index 0000000000..7c86f985c5 --- /dev/null +++ b/content/en/blog/_posts/2021-07-12-Kubernetes-Release-Cadence/index.md @@ -0,0 +1,84 @@ +--- +layout: blog +title: "Kuberentes Release Cadence Change: Here’s What You Need To Know" +date: 2021-07-01 +slug: new-kubernetes-release-cadence +--- + +REF: https://kubernetes.io/blog/2021/04/06/podsecuritypolicy-deprecation-past-present-and-future/ + + +**Authors**: Celeste Horgan, Adolfo García Veytia, James Laverack, Jeremy Rickard + +On April 23, 2021, the Release Team merged a Kubernetes Enhancement Proposal (KEP) changing the Kubernetes release cycle from four releases a year (once a quarter) to three releases a year. + +This blog post is a high level overview post for what this means for the Kubernetes community's contributors and maintainers. + +## What's changing and when + +Starting with the [Kubernetes 1.22 release](https://www.kubernetes.dev/resources/release/), a lightweight policy will drive the creation of each release schedule. This policy states: + +* The first Kubernetes release of a calendar year should start at the second or third + week of January to provide people more room after coming back from the + winter holidays. +* The last Kubernetes release of a calendar year should be finished by the middle of + December. +* A Kubernetes release cycle has a length of approximately 15 weeks. +* The week of KubeCon + CloudNativeCon is not considered a 'working week' for SIG Release. The Release Team will not hold meetings or make decisions in this period. +* An explicit SIG Release break of at least two weeks between each cycle will + be enforced. + +As a result, Kubernetes will follow a three release pear year cadence. Kubernetes 1.23 will be the final release of the 2021 calendar year. This new schedule creation policy results in a very predictible release schedule, allowing us to forecast upcoming release dates: + + +*Proposed Kubernetes Release Schedule for the remainder of 2021* + +| Week Number in Year | Release Number | Release Week | Note | +| -------- | -------- | -------- | -------- | +| 35 | 3 | 1 (August 23) | | +| 50 | 3 | 16 (December 07) | KubeCon + CloudNativeCon NA Break (Oct 11-15) | + +*Proposed Kubernetes Release Schedule for 2022* + +| Week Number in Year | Release Number | Release Week | Note | +| -------- | -------- | -------- | -------- | +| 1 | 1 | 1 (January 03) | | +| 15 | 1 | 15 (April 12) | | +| 17 | 2 | 1 (April 26) | KubeCon + CloudNativeCon EU likely to occur | +| 32 | 2 | 15 (August 09) | | +| 34 | 3 | 1 (August 22 | KubeCon + CloudNativeCon NA likely to occur | +| 49 | 3 | 14 (December 06) | + +These proposed dates reflect only the start and end dates, and they are subject to change. The Release Team will select dates for enhancement freeze, code freeze, and other milestones at the start of each release. Feedback from prior releases will feed into this process. + +## What this means for end users + +The only major change end users will experience is a slower release cadence. Kubernetes release artifacts, release notes, and all other aspects of any given release will stay the same. + +With less releases to consume per year, end user organizations will spend less time on upgrades and more time on supporting their Kubernetes clusters. It also means that Kubernetes releases are in support for a slightly longer period of time. + + +## What this means for Kubernetes contributors + +With a lower release cadence, contributors have more time for project enhancements, feature development, planning, and testing. A slower release cadence also provides more room for maintaining their mental health, preparing for events like KubeCon + CloudNativeCon or work on downstream integrations. + + +## Why we decided to change the release cadence + +The Kubernetes 1.19 cycle was far longer than usual. SIG Release extended it to lessen the burden on both Kubernetes contributors and Kubernetes end users due the COVID-19 pandemic. Following this extended release, the Kubernetes 1.20 release became the third, and final, release for 2020. + +As the Kubernetes project matures, the number of enhancements per cycle grows, along with the burden on contributors, the Release Engineering team. Downstream consumers and integrators also face increased challenges keeping up with [ever more feature-packed releases](https://kubernetes.io/blog/2021/04/08/kubernetes-1-21-release-announcement/). A wider project adoption means the complexity of supporting a rapidly evolving platform affects a bigger downstream chain of consumers. + +Changing the release cadence from four to three releases per year balances a variety of factors for stakeholders: while it's not strictly an LTS policy, consumers and integrators will get longer support terms for each minor version as the extended release cycles lead to the [last three releases being supported](https://kubernetes.io/blog/2020/08/31/kubernetes-1-19-feature-one-year-support/) for a longer period. Contributors get more time to [mature enhancements](https://www.cncf.io/blog/2021/04/12/enhancing-the-kubernetes-enhancements-process/) and [get them ready for production](https://github.com/kubernetes/community/blob/master/sig-architecture/production-readiness.md). + +Finally, the management overhead for SIG Release and the Release Engineering team diminishes allowing the team to spend more time on improving the quality of the software releases and the tooling that drives them. + +## How you can help + +Join the [discussion](https://github.com/kubernetes/sig-release/discussions/1566) about communicating future release dates and be sure to be on the lookout for post release surveys. + +## Where you can find out more + +- Read the KEP [here](https://github.com/kubernetes/enhancements/tree/master/keps/sig-release/2572-release-cadence) +- Join the [kubernetes-dev](https://groups.google.com/g/kubernetes-dev) mailing list +- Join [Kubernetes Slack](https://slack.k8s.io) and follow the #announcements channel \ No newline at end of file From da677ad55d1ab06c66c1b7cce1fc5799397d8881 Mon Sep 17 00:00:00 2001 From: Jeremy Rickard Date: Fri, 16 Jul 2021 13:33:05 -0600 Subject: [PATCH 2/7] Update content/en/blog/_posts/2021-07-12-Kubernetes-Release-Cadence/index.md Co-authored-by: Tim Bannister --- .../_posts/2021-07-12-Kubernetes-Release-Cadence/index.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/en/blog/_posts/2021-07-12-Kubernetes-Release-Cadence/index.md b/content/en/blog/_posts/2021-07-12-Kubernetes-Release-Cadence/index.md index 7c86f985c5..e7dd6c51c2 100644 --- a/content/en/blog/_posts/2021-07-12-Kubernetes-Release-Cadence/index.md +++ b/content/en/blog/_posts/2021-07-12-Kubernetes-Release-Cadence/index.md @@ -1,6 +1,6 @@ --- layout: blog -title: "Kuberentes Release Cadence Change: Here’s What You Need To Know" +title: "Kubernetes Release Cadence Change: Here’s What You Need To Know" date: 2021-07-01 slug: new-kubernetes-release-cadence --- @@ -81,4 +81,4 @@ Join the [discussion](https://github.com/kubernetes/sig-release/discussions/1566 - Read the KEP [here](https://github.com/kubernetes/enhancements/tree/master/keps/sig-release/2572-release-cadence) - Join the [kubernetes-dev](https://groups.google.com/g/kubernetes-dev) mailing list -- Join [Kubernetes Slack](https://slack.k8s.io) and follow the #announcements channel \ No newline at end of file +- Join [Kubernetes Slack](https://slack.k8s.io) and follow the #announcements channel From 7095fcce17330d122d6bbb2cb64dc4ae1a738033 Mon Sep 17 00:00:00 2001 From: Jeremy Rickard Date: Fri, 16 Jul 2021 13:34:16 -0600 Subject: [PATCH 3/7] Update content/en/blog/_posts/2021-07-12-Kubernetes-Release-Cadence/index.md Co-authored-by: Sascha Grunert --- .../blog/_posts/2021-07-12-Kubernetes-Release-Cadence/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/blog/_posts/2021-07-12-Kubernetes-Release-Cadence/index.md b/content/en/blog/_posts/2021-07-12-Kubernetes-Release-Cadence/index.md index e7dd6c51c2..0ef377ebc4 100644 --- a/content/en/blog/_posts/2021-07-12-Kubernetes-Release-Cadence/index.md +++ b/content/en/blog/_posts/2021-07-12-Kubernetes-Release-Cadence/index.md @@ -55,7 +55,7 @@ These proposed dates reflect only the start and end dates, and they are subject The only major change end users will experience is a slower release cadence. Kubernetes release artifacts, release notes, and all other aspects of any given release will stay the same. -With less releases to consume per year, end user organizations will spend less time on upgrades and more time on supporting their Kubernetes clusters. It also means that Kubernetes releases are in support for a slightly longer period of time. +With less releases to consume per year, it's intended that end user organizations will spend less time on upgrades and gain more time on supporting their Kubernetes clusters. It also means that Kubernetes releases are in support for a slightly longer period of time. ## What this means for Kubernetes contributors From bef5681585cfd1a764eab699d2c6c815a7daecca Mon Sep 17 00:00:00 2001 From: Jeremy Rickard Date: Fri, 16 Jul 2021 13:34:31 -0600 Subject: [PATCH 4/7] Update content/en/blog/_posts/2021-07-12-Kubernetes-Release-Cadence/index.md Co-authored-by: Sascha Grunert --- .../blog/_posts/2021-07-12-Kubernetes-Release-Cadence/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/blog/_posts/2021-07-12-Kubernetes-Release-Cadence/index.md b/content/en/blog/_posts/2021-07-12-Kubernetes-Release-Cadence/index.md index 0ef377ebc4..7acaeda4e3 100644 --- a/content/en/blog/_posts/2021-07-12-Kubernetes-Release-Cadence/index.md +++ b/content/en/blog/_posts/2021-07-12-Kubernetes-Release-Cadence/index.md @@ -12,7 +12,7 @@ REF: https://kubernetes.io/blog/2021/04/06/podsecuritypolicy-deprecation-past-pr On April 23, 2021, the Release Team merged a Kubernetes Enhancement Proposal (KEP) changing the Kubernetes release cycle from four releases a year (once a quarter) to three releases a year. -This blog post is a high level overview post for what this means for the Kubernetes community's contributors and maintainers. +This blog post provides a high level overview about what this means for the Kubernetes community's contributors and maintainers. ## What's changing and when From 85d8b843d3e52556aebc5a3b9643946edcbcd7e1 Mon Sep 17 00:00:00 2001 From: Jeremy Rickard Date: Fri, 16 Jul 2021 13:55:09 -0600 Subject: [PATCH 5/7] Update content/en/blog/_posts/2021-07-12-Kubernetes-Release-Cadence/index.md Co-authored-by: Sascha Grunert --- .../blog/_posts/2021-07-12-Kubernetes-Release-Cadence/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/blog/_posts/2021-07-12-Kubernetes-Release-Cadence/index.md b/content/en/blog/_posts/2021-07-12-Kubernetes-Release-Cadence/index.md index 7acaeda4e3..aa31edb80c 100644 --- a/content/en/blog/_posts/2021-07-12-Kubernetes-Release-Cadence/index.md +++ b/content/en/blog/_posts/2021-07-12-Kubernetes-Release-Cadence/index.md @@ -65,7 +65,7 @@ With a lower release cadence, contributors have more time for project enhancemen ## Why we decided to change the release cadence -The Kubernetes 1.19 cycle was far longer than usual. SIG Release extended it to lessen the burden on both Kubernetes contributors and Kubernetes end users due the COVID-19 pandemic. Following this extended release, the Kubernetes 1.20 release became the third, and final, release for 2020. +The Kubernetes 1.19 cycle was far longer than usual. SIG Release extended it to lessen the burden on both Kubernetes contributors and end users due the COVID-19 pandemic. Following this extended release, the Kubernetes 1.20 release became the third, and final, release for 2020. As the Kubernetes project matures, the number of enhancements per cycle grows, along with the burden on contributors, the Release Engineering team. Downstream consumers and integrators also face increased challenges keeping up with [ever more feature-packed releases](https://kubernetes.io/blog/2021/04/08/kubernetes-1-21-release-announcement/). A wider project adoption means the complexity of supporting a rapidly evolving platform affects a bigger downstream chain of consumers. From d77ab6d2b96dce5a7e2938365408730189c630fa Mon Sep 17 00:00:00 2001 From: Jeremy Date: Fri, 16 Jul 2021 13:56:10 -0600 Subject: [PATCH 6/7] Review feedback Signed-off-by: Jeremy --- .../index.md | 33 +++++++++---------- 1 file changed, 16 insertions(+), 17 deletions(-) diff --git a/content/en/blog/_posts/2021-07-12-Kubernetes-Release-Cadence/index.md b/content/en/blog/_posts/2021-07-12-Kubernetes-Release-Cadence/index.md index aa31edb80c..f2badbfdc1 100644 --- a/content/en/blog/_posts/2021-07-12-Kubernetes-Release-Cadence/index.md +++ b/content/en/blog/_posts/2021-07-12-Kubernetes-Release-Cadence/index.md @@ -5,9 +5,6 @@ date: 2021-07-01 slug: new-kubernetes-release-cadence --- -REF: https://kubernetes.io/blog/2021/04/06/podsecuritypolicy-deprecation-past-present-and-future/ - - **Authors**: Celeste Horgan, Adolfo García Veytia, James Laverack, Jeremy Rickard On April 23, 2021, the Release Team merged a Kubernetes Enhancement Proposal (KEP) changing the Kubernetes release cycle from four releases a year (once a quarter) to three releases a year. @@ -16,7 +13,7 @@ This blog post provides a high level overview about what this means for the Kube ## What's changing and when -Starting with the [Kubernetes 1.22 release](https://www.kubernetes.dev/resources/release/), a lightweight policy will drive the creation of each release schedule. This policy states: +Starting with the [Kubernetes 1.22 release](https://github.com/kubernetes/sig-release/tree/master/releases/release-1.22), a lightweight policy will drive the creation of each release schedule. This policy states: * The first Kubernetes release of a calendar year should start at the second or third week of January to provide people more room after coming back from the @@ -28,34 +25,36 @@ Starting with the [Kubernetes 1.22 release](https://www.kubernetes.dev/resources * An explicit SIG Release break of at least two weeks between each cycle will be enforced. -As a result, Kubernetes will follow a three release pear year cadence. Kubernetes 1.23 will be the final release of the 2021 calendar year. This new schedule creation policy results in a very predictible release schedule, allowing us to forecast upcoming release dates: +As a result, Kubernetes will follow a three release pear year cadence. Kubernetes 1.23 will be the final release of the 2021 calendar year. This new policy results in a very predictable release schedule, allowing us to forecast upcoming release dates: *Proposed Kubernetes Release Schedule for the remainder of 2021* | Week Number in Year | Release Number | Release Week | Note | | -------- | -------- | -------- | -------- | -| 35 | 3 | 1 (August 23) | | -| 50 | 3 | 16 (December 07) | KubeCon + CloudNativeCon NA Break (Oct 11-15) | +| 35 | 1.23 | 1 (August 23) | | +| 50 | 1.23 | 16 (December 07) | KubeCon + CloudNativeCon NA Break (Oct 11-15) | *Proposed Kubernetes Release Schedule for 2022* | Week Number in Year | Release Number | Release Week | Note | | -------- | -------- | -------- | -------- | -| 1 | 1 | 1 (January 03) | | -| 15 | 1 | 15 (April 12) | | -| 17 | 2 | 1 (April 26) | KubeCon + CloudNativeCon EU likely to occur | -| 32 | 2 | 15 (August 09) | | -| 34 | 3 | 1 (August 22 | KubeCon + CloudNativeCon NA likely to occur | -| 49 | 3 | 14 (December 06) | +| 1 | 1.24 | 1 (January 03) | | +| 15 | 1.24 | 15 (April 12) | | +| 17 | 1.25 | 1 (April 26) | KubeCon + CloudNativeCon EU likely to occur | +| 32 | 1.25 | 15 (August 09) | | +| 34 | 1.26 | 1 (August 22 | KubeCon + CloudNativeCon NA likely to occur | +| 49 | 1.26 | 14 (December 06) | -These proposed dates reflect only the start and end dates, and they are subject to change. The Release Team will select dates for enhancement freeze, code freeze, and other milestones at the start of each release. Feedback from prior releases will feed into this process. +These proposed dates reflect only the start and end dates, and they are subject to change. The Release Team will select dates for enhancement freeze, code freeze, and other milestones at the start of each release. For more information on these milestones, please refer to the [release phases](https://www.k8s.dev/resources/release/#phases) documentation. Feedback from prior releases will feed into this process. ## What this means for end users -The only major change end users will experience is a slower release cadence. Kubernetes release artifacts, release notes, and all other aspects of any given release will stay the same. +The major change end users will experience is a slower release cadence and a slower rate of enhancement graduation. Kubernetes release artifacts, release notes, and all other aspects of any given release will stay the same. -With less releases to consume per year, it's intended that end user organizations will spend less time on upgrades and gain more time on supporting their Kubernetes clusters. It also means that Kubernetes releases are in support for a slightly longer period of time. +Prior to this change an enhancement could graduate from alpha to stable in 9 months. With the change in cadence, this will stretch to 12 months. Additionally, graduation of features over the last few releases has in some part been driven by release team activities. + +With fewer releases, users can expect to see the rate of feature graduation slow. Users can also expect releases to contain a larger number of enhancements that they need to be aware of during upgrades. However, with fewer releases to consume per year, it's intended that end user organizations will spend less time on upgrades and gain more time on supporting their Kubernetes clusters. It also means that Kubernetes releases are in support for a slightly longer period of time, so bug fixes and security patches will be available for releases for a longer period of time. ## What this means for Kubernetes contributors @@ -69,7 +68,7 @@ The Kubernetes 1.19 cycle was far longer than usual. SIG Release extended it to As the Kubernetes project matures, the number of enhancements per cycle grows, along with the burden on contributors, the Release Engineering team. Downstream consumers and integrators also face increased challenges keeping up with [ever more feature-packed releases](https://kubernetes.io/blog/2021/04/08/kubernetes-1-21-release-announcement/). A wider project adoption means the complexity of supporting a rapidly evolving platform affects a bigger downstream chain of consumers. -Changing the release cadence from four to three releases per year balances a variety of factors for stakeholders: while it's not strictly an LTS policy, consumers and integrators will get longer support terms for each minor version as the extended release cycles lead to the [last three releases being supported](https://kubernetes.io/blog/2020/08/31/kubernetes-1-19-feature-one-year-support/) for a longer period. Contributors get more time to [mature enhancements](https://www.cncf.io/blog/2021/04/12/enhancing-the-kubernetes-enhancements-process/) and [get them ready for production](https://github.com/kubernetes/community/blob/master/sig-architecture/production-readiness.md). +Changing the release cadence from four to three releases per year balances a variety of factors for stakeholders: while it's not strictly an LTS policy, consumers and integrators will get longer support terms for each minor version as the extended release cycles lead to the [previous three releases being supported](https://kubernetes.io/blog/2020/08/31/kubernetes-1-19-feature-one-year-support/) for a longer period. Contributors get more time to [mature enhancements](https://www.cncf.io/blog/2021/04/12/enhancing-the-kubernetes-enhancements-process/) and [get them ready for production](https://github.com/kubernetes/community/blob/master/sig-architecture/production-readiness.md). Finally, the management overhead for SIG Release and the Release Engineering team diminishes allowing the team to spend more time on improving the quality of the software releases and the tooling that drives them. From d4052254154fc81eb851108a5fdb5acd1dc3e830 Mon Sep 17 00:00:00 2001 From: Jeremy Date: Mon, 19 Jul 2021 14:08:14 -0600 Subject: [PATCH 7/7] Change date for blog post Signed-off-by: Jeremy --- .../index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) rename content/en/blog/_posts/{2021-07-12-Kubernetes-Release-Cadence => 2021-07-20-Kubernetes-Release-Cadence}/index.md (99%) diff --git a/content/en/blog/_posts/2021-07-12-Kubernetes-Release-Cadence/index.md b/content/en/blog/_posts/2021-07-20-Kubernetes-Release-Cadence/index.md similarity index 99% rename from content/en/blog/_posts/2021-07-12-Kubernetes-Release-Cadence/index.md rename to content/en/blog/_posts/2021-07-20-Kubernetes-Release-Cadence/index.md index f2badbfdc1..3f563cedfb 100644 --- a/content/en/blog/_posts/2021-07-12-Kubernetes-Release-Cadence/index.md +++ b/content/en/blog/_posts/2021-07-20-Kubernetes-Release-Cadence/index.md @@ -1,7 +1,7 @@ --- layout: blog title: "Kubernetes Release Cadence Change: Here’s What You Need To Know" -date: 2021-07-01 +date: 2021-07-20 slug: new-kubernetes-release-cadence ---