Closed SergeyKanzhelev closed 4 years ago
Thanks! Lets hold this until the feature PR merges.
This also means we have to release a new Minor of this library and revendor it in k/k.
/lgtm /approve /hold
[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: neolit123, SergeyKanzhelev
The full list of commands accepted by this bot can be found here.
The pull request process is described here
/kind feature /priority important-longterm
@neolit123: The label(s) priority/
cannot be applied, because the repository doesn't have them
PR in k/k got merged. I wonder if I can cancel hold on self-authored PR...
/hold cancel
@SergeyKanzhelev do you happen to know if there are other planned features from SIG node related to this repository?
@SergeyKanzhelev do you happen to know if there are other planned features from SIG node related to this repository?
I don't think so after briefly looking thru the code. even for this change, cutting release is not critical as it is not a breaking change. So perhaps, this can wait in case something else will come up
ok, since this library's "release process" is a bit bottlenecked on my availability, i'd prefer if we cut the release now and re-vendor in k/k right away to unblock tests if needed(?).
and we can cut more releases here if needed for 1.20 later.
here is the new release: https://github.com/kubernetes/system-validators/releases/tag/v1.2.0
would you be able to send the PR to re-vendor?
here is an example commit on how we update the vendor: https://github.com/kubernetes/kubernetes/commit/8183787493472b2d9a7006f78da63cd589456f81
it uses the script: https://github.com/kubernetes/kubernetes/blob/master/hack/pin-dependency.sh
here is the new release: https://github.com/kubernetes/system-validators/releases/tag/v1.2.0
would you be able to send the PR to re-vendor?
Yes, thank you for the detailed instructions!
Follow up from https://github.com/kubernetes/kubernetes/pull/94140