-
Notifications
You must be signed in to change notification settings - Fork 3.3k
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Figure out a plan to update release branches automatically #177
Comments
Issues go stale after 90d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
Stale issues rot after 30d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
Rotten issues close after 30d of inactivity. Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
@fejta-bot: Closing this issue. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
/reopen |
@micw523: Reopened this issue. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
Is this issue still open ? shall i work on it ? |
Release branches in client-python are following a release branch in kubernetes main repo. If there is a patch for main repo's branch, we should figure out a way to at least detect it, even better create a PR automatically and even much better merge that PR if it is backward compatible.
I would consider this task done if we create a PR automatically. Merging on backward compatibility would be just a plus.
The text was updated successfully, but these errors were encountered: