-
Notifications
You must be signed in to change notification settings - Fork 398
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
patches: Add maintenance mode dates, updated EOLs, and final v1.18 release #1532
Conversation
/hold for discussion |
8996727
to
fe40c20
Compare
releases/patch-releases.md
Outdated
|
||
| PATCH RELEASE | CHERRY PICK DEADLINE | TARGET DATE | | ||
|--- |--- |--- | | ||
| 1.18.19 | 2021-04-26 | 2021-04-28 | |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would like to propose final patch release for 1.18 on 5/7/21 with the rest of the active branch patches. This is simpler for folks trying to get cherry picks backported to all branches, and also provides more time given that we are a bit late communicating this date.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@hasheddan -- I'd like to minimize how much longer we keep the 1.18 branch around, as it's running on go1.13.15 (which is out of support upstream).
The thought process around the 28th was although it deviates from the patch release schedule month-to-month, it allows us to give a very consistent response about when a release in entering maintenance mode or going EOL; it's always the 28th of the designated month.
A consideration for a follow-up 👇🏾
Are we okay with 5/7 as a patch release date next month? That falls within the week of KubeCon.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That sounds like a good policy (having final patch be on the 28th of the EOL month), but I would encourage us to consider enacting that post 1.18 as we are already close to the deadline and some folks have made the assumption (reasonably) that if we were to have one more patch it would be aligned with the other branches. We should also consider any future confusion this could introduce with folks opening CPs to branches that have different CP deadlines when the oldest active branch is reaching EOL.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
some folks have made the assumption (reasonably) that if we were to have one more patch it would be aligned with the other branches
@hasheddan -- Great point. Updated!
Are we okay with 5/7 as a patch release date next month? That falls within the week of KubeCon.
Don't mind me. Looking again, I see that this is the cherry pick deadline, with the patches to happen the week after (which should be fine).
Much clearer, thanks 😊 |
Signed-off-by: Stephen Augustus <[email protected]>
Signed-off-by: Stephen Augustus <[email protected]>
Signed-off-by: Stephen Augustus <[email protected]>
Signed-off-by: Stephen Augustus <[email protected]>
Signed-off-by: Stephen Augustus <[email protected]>
fe40c20
to
b33c5d0
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thanks for the update and make sense to me
/lgtm
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/lgtm
Let's wrap-up those changes in a mail, too.
Should we also update |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Other than the comment I left, this looks great to me. Thank you for taking care of this!
/lgtm
During the two-month maintenance mode period, Release Managers may cut | ||
additional maintenance releases to resolve: | ||
|
||
- CVEs (under the advisement of the Product Security Committee) | ||
- dependency issues (including base image updates) | ||
- critical core component issues |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are we going to allow other changes in the maintenance mode period?
I guess that one option is that we might allow them if we are fixing one of those three issues specified here, but otherwise, we wouldn't cut a release only because of other changes. Another option is that we don't allow other changes non-related to those at all.
Should we make that clear in the document?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/lgtm
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: cpanato, hasheddan, justaugustus, saschagrunert, xmudrii 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 |
/hold cancel |
Note to the community to pre-announce May's patch releases and extending EOLs with a maintenance mode: https://groups.google.com/g/kubernetes-announce/c/Vixft2lPyaA |
What type of PR is this:
/kind cleanup documentation feature
What this PR does / why we need it:
/assign @hasheddan @saschagrunert @xmudrii
cc: @kubernetes/sig-release-leads @kubernetes/release-managers
ref:
Which issue(s) this PR fixes:
Special notes for your reviewer: