Replies: 7 comments 9 replies
-
OK, one con to cut it on April 14th is that I see the time window to get the go bump ready. Depending on the time the images are available we could end up having less than a day to do it. This means that the release could slip to Friday which we generally try to avoid. Also, it falls right on the Easter holidays, so I'm wondering about the availability of folks around those dates. |
Beta Was this translation helpful? Give feedback.
-
cc @kubernetes/release-team-leads for awareness |
Beta Was this translation helpful? Give feedback.
-
Another point to consider: Regardless of when we cut rc.0 we are looking at a delay of one week at least. We need to allow time for downstream users to run their tests against the rc. This is the week starting Monday 18:
|
Beta Was this translation helpful? Give feedback.
-
@kubernetes/release-team-leads @kubernetes/release-managers @dims @liggitt -- All, after discussing with @kubernetes/sig-release-leads, let's jump back into this thread and discuss a notional delayed release date of Tuesday, May 3rd. A few points to consider:
WDYT? |
Beta Was this translation helpful? Give feedback.
-
I agree with a two-week delay to Tuesday 3rd May for the 1.24 release date. I'd like to avoid multiple delays. If we're going to delay we should do it once and commit. I also don't want us to rush anything, which might result in rapidly needing to ship a 1.24.1 (or 😱 1.24.2) patch release. Both of these would erode community confidence in our process IMO. I'm aware of the impact that a two-week delay could have on the release team as a whole. In our Monday 11th April burndown meeting, I already mentioned to the team that it's okay if people can't stay on past the original 15-week commitment and to speak to @jrsapi or myself if they have concerns. I also agree with not cutting a release on a Monday or Friday. I think cutting an rc.0 without the Go 1.18.1 fix is a bit pointless, so I'm in agreement that it should wait until Go 1.18.1 until rc.0. There's a possible impact on 1.25 (and further) releases, cc @cici37 and @reylejano (1.25 Lead and EA). I'm unsure if it's safe to do some 1.25 spin-up tasks while 1.24 is concluding. Or if it's best to conclude 1.24 completely and push back 1.25 a bit too? I'm also concious that this will mean that k/k's master branch will remain frozen for longer. Which may delay some folk from merging things. In general though, I don't intend to permit any exception requests for bugs that are not critical at this stage, even with the extension. I'd also like to wait until the Go 1.18.1 release actually drops and we confrm our fix is in there, before we communicate out. If Go delays again we'll have to revise this schedule. |
Beta Was this translation helpful? Give feedback.
-
@justaugustus @kubernetes/release-team @liggitt - golang folks are still on for 1.18.1 tomorrow ( https://groups.google.com/g/golang-nuts/c/9A-3jOOW4VI/m/10oNeQ93FwAJ ) @JamesLaverack the fix we were waiting on has already merged in golang 1.18 branch. so yes we should see it in 1.18.1 tomorrow. |
Beta Was this translation helpful? Give feedback.
-
Given this discussion, and after some debate in the Tuesday 12th April 2022 SIG Release Engineering meeting, as Release Lead I'm resolving to implement Stephen's plan above and ℹ️ delay the Kubernetes 1.24 scheduled release date to Tuesday 3rd May 2022 ℹ️ . Going forwards we should:
|
Beta Was this translation helpful? Give feedback.
-
Since we are waiting for a fix(issue detail) in go1.18.1, and go1.18.1 release was pushed to Tuesday, April 12th(GO Announcement), here is the discussion on how we should push 1.24 release dates.
Due to the slack discussion in sig-release channel, the currently propose is to push:
Please feel free to leave your opinion.
Beta Was this translation helpful? Give feedback.
All reactions