[v1.17] chore(deps): revert etcd bump to v3.6.0 #39628
Conversation
Partially revert eee00a6 ("chore(deps): update all-dependencies") to undo the etcd upgrade to v3.6.0. This matches the newly adopted policy of only performing patch version upgrades in stable branches, to prevent introducing unnecessary churn due to possible API changes. It is safe to revert this change, as not part of any release. Related: 592f7b0 ("renovate: only perform etcd patch version updates in stable branches") Signed-off-by: Marco Iorio <marco.iorio@isovalent.com>
84eefc8 to
346456b
Compare
|
Updated the commit message to reference the renovate change. |
|
/test |
I thought this was a long-standing policy :) Was there a specific link for this? I guess that this page would be the obvious place to properly document the pattern. |
This is specifically referring to the etcd binary bundled as part of the clustermesh-apiserver image, and (mostly as a byproduct) the etcd version used for integration tests. Currently, renovate was configured to perform the upgrade on stable branches as well together with the other dependencies, and we mostly noticed due to a minor incompatibility that caused clustermesh E2E tests to basically fail. This is the first time that this topic is being brought up because it is the first etcd minor release cut since we started directly bundling etcd as part of the clustermesh-apiserver image (Cilium v1.15 IIRC) for additional control, and to prevent issues due to version mismatches like this, while it used to be user-configurable before. I think you may referring to the etcd go client version instead, which (similarly to the other go dependencies), is already configured to be only bumped on the main branch (and responsibility of the vendor team), to prevent unnecessary churn and the possible associated risks. |
Partially revert eee00a6 ("chore(deps): update all-dependencies") to undo the etcd upgrade to v3.6.0. This matches the newly adopted policy of only performing patch version upgrades in stable branches, to prevent introducing unnecessary churn due to possible API changes.
It is safe to revert this change, as not part of any release.