The PR looks good, but I am not sure whether it's OK to let this PR in at current stage.

Based on https://github.com/kubernetes/sig-release/tree/master/releases/release-1.35, Kubernetes 1.35 has already entered into code freeze.

/sig etcd
/triage accepted
/priority important-longterm

/lgtm

cc @dims @liggitt @hakman @joshjms

@kubernetes/release-managers

LGTM label has been added.

It looks like there are no code changes outside the server package, which we only use for tests. If there are no code changes in the client packages which actually affect the binaries we ship, we can just wait for master to reopen for 1.36 to merge

/lgtm
/approve

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: liggitt, yashsingh74

The full list of commands accepted by this bot can be found here.

The pull request process is described here

It looks like there are no code changes outside the server package, which we only use for tests. If there are no code changes in the client packages which actually affect the binaries we ship, we can just wait for master to reopen for 1.36 to merge

Should we actually bump a dependency if there are no code changes?

I think the key question is: should we bump etcd client SDK for release branches?

Two completely opposite opinions,

• Usually we don't bump dependencies for a release branch unless there is major+ bug fixes or CVE fixes. From this point, we shouldn't bump etcd client SDK for release branches.
• [preferred] But for etcd, it's recommended to test the matched client SDK and etcdserver versions, although the protocol between etcd client and server are stable. From this point, we should bump etcd client SDK together with image version for both master and release branches.

also see etcd-io/etcd#20936

There is already an opened changes for etcd 3.6.6 SDK - #135270

Are we planning to merge with 1.35 release ??

@yashsingh74 I think the plan is to merge in 1.36. For now, there is no issue that needs to be fixed by this update in 1.35.