downgrade go-difflib and go-spew to tagged releases #11220
Conversation
These dependencies were updated to "master" in some modules we depend on, but have no code-changes since their last release. Unfortunately, this also causes a ripple effect, forcing all users of the containerd module to also update these dependencies to an unrelease / un-tagged version. Both these dependencies will unlikely do a new release in the near future, so exclude these versions so that we can downgrade to the current release. For additional details, see [this PR][1] and links mentioned in it. [1]: kubernetes-sigs/kustomize#5830 (comment) Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
austinvazquez
left a comment
There was a problem hiding this comment.
LGTM, thanks for the detail and context.
Oh! You're welcome! It was definitely a bit of a "down the rabbit hole" case. The TL;DR of this PR is that it may take some time for all of our (indirect) dependencies to be updates and remove the wrong versions. We don't control those, but at least with this PR we can cut the cycle, and help downstream users of containerd to start downgrading. Ultimately this should go away, but having this in place can help speed up the process, e.g. I found this when updating BuildKit and Moby to containerd v2, and those also depended on Nydus (and other snapshotters), which had to update because of containerd. I may still have to end up doing similar PRs in BuildKit and Moby, but hopefully this helps speeding up cutting the cycle. |
|
/cherrypick release/2.0 |
|
@thaJeztah: new pull request created: #11222 DetailsIn 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-sigs/prow repository. |
These dependencies were updated to "master" in some modules we depend on, but have no code-changes since their last release. Unfortunately, this also causes a ripple effect, forcing all users of the containerd module to also update these dependencies to an unrelease / un-tagged version.
Both these dependencies will unlikely do a new release in the near future, so exclude these versions so that we can downgrade to the current release.
For additional details, see this PR and links mentioned in it.