Create 1.33 release directory #2706
Conversation
k8s-ci-robot
added
do-not-merge/work-in-progress
k8s-ci-robot
added
needs-priority
area/release-team
k8s-ci-robot
removed
the
do-not-merge/work-in-progress
releases/release-1.33/README.md
Outdated
| | **Begin Feature blog freeze** | Comms Lead | 02:00 UTC Wednesday 26th February 2025 / 19:00 PDT Tuesday 25th February 2025 | week 8 | | | ||
| | Deprecations and Removals blog published | Comms | Monday 3th March 2025 | week 9 | | | ||
| | 1.33.0-beta.0 released | Branch Manager | Tuesday 4th March 2025 | week 9 | | | ||
| | **Begin [Code Freeze] and [Test Freeze]** | Branch Manager | 02:00 UTC Friday 7th March 2025 / 19:00 PDT Thursday 6th March 2025 | week 9 | | |
There was a problem hiding this comment.
This looks at least 1 week too early. It gives us only 3 weeks for code/test. We need at least 4 weeks, which is what we had in 1.32 and that was actually the shortest code+test we had in the last 12 releases...
There was a problem hiding this comment.
I agree that it feels very rushed - we have a 3 month cycle and 1/4 of it is development.
That said...
This timeline indicates that the cycle begins Jan 13. But really, it began the moment the tree unfroze. So we have (had) a lot more than just 3 weeks for dev. But the holidays ate all of December, so in PRACTICE, not really.
I don't know how to break the cycle. Every cycle it feels like it gets shorter and less dev-time, then we all argue about it and then we extend it. Can we make it policy to have no less than 4 for dev?
During the March 6-25 window, why can't we continue to allow development, perhaps with the bar higher, but not as high as the final stabilization?
There was a problem hiding this comment.
Can we make it policy to have no less than 4 for dev?
Definitely agree wrt making a strict policy for 4 dev weeks after the enhancement freeze.
There was a problem hiding this comment.
First of all the math here doesn't add up wrt weeks (comparing current dates with last release:
W1: 1/13 (Monday first day of week 1)
W2: 1/20
W3: 1/27
W3: 2/03
W4: 2/10
W5: 2/17
W6: 2/24
W7: 3/03
W8: 3/10
W9: 3/17
So at minimum I'd expect 3/17 to be the code freeze. But I'm willing to support John's proposal of 3/20, but that means W10, not 11 based on what I wrote above.
There was a problem hiding this comment.
I agree- I think Week 10 code freeze will give people more time. @katcosgrove would this work with the docs deadlines?
There was a problem hiding this comment.
I am fine with pushing code freeze to week 10. Week 11 is too close to Docs Freeze, considering SIGs already struggle to meet documentation deadlines. I am unwilling to increase pressure on Release Docs and SIG Docs by shortening that timeline even further.
There was a problem hiding this comment.
Ok, so that is the Thursday of Week 10, which starts on 3/24 based on @soltysh's calculations? In other words, 3/27?
Or did you mean 3/20 @katcosgrove ? It seems the math was wrong at some point?
There was a problem hiding this comment.
I meant week 10, 3/20. I think the dates and week mappings are fixed here now: https://github.com/kubernetes/sig-release/blob/86947d89fc9958baecf88c66c2336fb3f51b4ab7/releases/release-1.33/README.md
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: npolshakova The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
releases/release-1.33/README.md
Outdated
| | Start Enhancements Tracking | Enhancements Lead | Monday 13th January 2025 | week 1 | | | ||
| | Schedule finalized | Lead | Friday 17th January 2025 | week 1 | | | ||
| | Team finalized | Lead | Friday 17th January 2025 | week 1 | | | ||
| | Begin Friday APAC-friendly meetings | Lead | Wednesday 2nd January 2025 | week 2 | | |
There was a problem hiding this comment.
the dates are all messed up here, this is causing confusion. Can we fix the dates? See #2706 (comment)
There was a problem hiding this comment.
| | Deprecations and Removals blog published | Comms | Monday 24th March 2025 | week 11 | | | ||
| | **Preparing for Feature blogs review — Initiating outreach** | Comms | Monday 24th March 2025 | week 11 | | | ||
| | Docs deadline — PRs ready for review | Docs Lead | Tuesday 25th March 2025 | week 11 | | | ||
| | Release Highlights deadline | Comms | Tuesday 25th March 2025 | week 11 | | |
There was a problem hiding this comment.
@mbianchidev @rytswd Updated the Release Highlights deadline to be before Release blog ready to review based on https://kubernetes.slack.com/archives/C2C40FMNF/p1736496690555129?thread_ts=1735581655.943799&cid=C2C40FMNF. Let me know how this looks like from the Comms perspective.
What type of PR is this:
/kind documentation
What this PR does / why we need it:
Creates the 1.33 release directory as per #2705
Which issue(s) this PR fixes:
None
Special notes for your reviewer: