Adding a blog to discuss release cadence change #28912
Conversation
k8s-ci-robot
added
the
cncf-cla: yes
k8s-ci-robot
added
area/blog
| slug: new-kubernetes-release-cadence | ||
| --- | ||
|
|
||
| REF: https://kubernetes.io/blog/2021/04/06/podsecuritypolicy-deprecation-past-present-and-future/ |
There was a problem hiding this comment.
Need to remove this
|
✔️ Deploy Preview for kubernetes-io-main-staging ready! 🔨 Explore the source changes: d405225 🔍 Inspect the deploy log: https://app.netlify.com/sites/kubernetes-io-main-staging/deploys/60f5dbd0c187500007c5be29 😎 Browse the preview: https://deploy-preview-28912--kubernetes-io-main-staging.netlify.app |
|
✔️ Deploy Preview for kubernetes-io-main-staging ready! 🔨 Explore the source changes: 9f501d0 🔍 Inspect the deploy log: https://app.netlify.com/sites/kubernetes-io-main-staging/deploys/60ec771b49236b684ce140b2 😎 Browse the preview: https://deploy-preview-28912--kubernetes-io-main-staging.netlify.app |
content/en/blog/_posts/2021-07-12-Kubernetes-Release-Cadence/index.md
Outdated
Show resolved
Hide resolved
|
|
||
| ## 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: |
There was a problem hiding this comment.
https://www.kubernetes.dev/resources/release/ will link to 1.23 if it's going to be released, right? If so, can we find a link which always points to 1.22?
There was a problem hiding this comment.
There was a problem hiding this comment.
updated to use the sig-release repo link from @palnabarun
| * 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: |
There was a problem hiding this comment.
"schedule" is used twice within the sentence, let's find a synonym for one of both.
There was a problem hiding this comment.
Change "three release pear year" to "three release per year"
| | 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) | |
There was a problem hiding this comment.
I'd suggest exchanging the "Release Number" with the actual release version. How about putting it in one table to make everything more compact, like:
| Calendar Weeks | Release | Timespan | Duration in Weeks | Note |
|---|---|---|---|---|
| 35-50 | v1.22 | Aug 23 - Dec 07 | 16 | KubeCon NA Break (Oct 11-15) |
| 1-15 | v1.23 | Jan 3 - Apr 12 | 15 | |
| 17-32 | v1.24 | Apr 26 - Aug 9 | 15 | KubeCon EU likely to occur |
| 34-49 | v1.25 | Aug 22 - Dec 6 | 14 | KubeCon NA likely to occur |
| | 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. |
There was a problem hiding this comment.
Let's link the releases phases here: https://github.com/kubernetes/sig-release/blob/master/releases/release_phases.md
There was a problem hiding this comment.
Could also link via https://www.k8s.dev/resources/release/#phases if that looks better.
content/en/blog/_posts/2021-07-12-Kubernetes-Release-Cadence/index.md
Outdated
Show resolved
Hide resolved
content/en/blog/_posts/2021-07-12-Kubernetes-Release-Cadence/index.md
Outdated
Show resolved
Hide resolved
|
/assign @saschagrunert @justaugustus |
|
|
||
| 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). |
There was a problem hiding this comment.
Perhaps change "last three releases being supported" to "previous three releases being supported"
|
|
||
| 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 |
There was a problem hiding this comment.
You don't mention any downside for changing the release cadence. If there is none, then that's fine. But I'm wondering if there will be some impact of fixes or enhancements having to wait for a longer period of time. Is there something built into the new cadence that can mitigate those potential negative effects?
There was a problem hiding this comment.
I can add this, I think we addressed it in the KEP so I'll paraphrase that content here, if that works?
There was a problem hiding this comment.
Yes. That was the only thing I wondered after reading the whole document.
There was a problem hiding this comment.
The negatives really come down to slower feature graduation and velocity. There isn't much that can be mitigated, it's just a result of the current policy around graduation (number of releases) and time. I've added information for users to be aware of the impact.
| --- | ||
| layout: blog | ||
| title: "Kuberentes Release Cadence Change: Here’s What You Need To Know" | ||
| date: 2021-07-01 |
There was a problem hiding this comment.
This date is a bit in the past, Do we know a future date that this blog post will be out? I do not want to put pressure on you, I want to reference this blog post in the Major themes for the 1.22 release notes.
There was a problem hiding this comment.
https://kubernetes.io/docs/contribute/new-content/blogs-case-studies/ has some more context on this (but could be more clear). The blog team can pick a date and update it to be in the future, so long as maintainer pushes to the source fork are permitted.
There was a problem hiding this comment.
The first challenge here is finding folks to do the first-pass review; once that's happened, I think it'll be easier to get a date set.
content/en/blog/_posts/2021-07-12-Kubernetes-Release-Cadence/index.md
Outdated
Show resolved
Hide resolved
…ndex.md Co-authored-by: Tim Bannister <[email protected]>
…ndex.md Co-authored-by: Sascha Grunert <[email protected]>
…ndex.md Co-authored-by: Sascha Grunert <[email protected]>
…ndex.md Co-authored-by: Sascha Grunert <[email protected]>
Signed-off-by: Jeremy <[email protected]>
|
@justaugustus @saschagrunert @sftim @chrisnegus I think I've addressed all comments so far, could you take another pass? @sftim any other reviewers you can suggest? |
k8s-ci-robot
added
the
lgtm
|
LGTM label has been added. Git tree hash: ee8f2666dfc2fd5279e6a7d2cbb23e959fcacdf6
|
|
@jeremyrickard - this looks good to me! The final piece would be to update the date to tomorrow or Wednesday this week and we can approve (barring any other feedback that arises). 🙌🏼 |
Signed-off-by: Jeremy <[email protected]>
k8s-ci-robot
removed
the
lgtm
k8s-ci-robot
added
the
lgtm
|
LGTM label has been added. Git tree hash: b709dcc50ec4a90d69742bcfc6fdc293034012ea
|
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: cpanato, onlydole, saschagrunert The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
k8s-ci-robot
added
the
approved
Adding a blog discussing the release cadence changes brought about by the release cadence kep, in advance of the 1.23 release (which will be the last one for the year).