Can we not do this? I don't understand the purpose of this bump since there are no changes in c/image.

There is no need to strictly bump c/image and c/common just because there is a new c/storage unless there are actual changes in them. We can directly bump c/storage in podman, buildah, skopeo which works the same.

I am saying this because each of these releases puts extra burden on us, not just the extra release PR, the new version then triggers downgrades per go modules versions until we merge back branches which is annoying to deal with.
i.e. #2755 and containers/common#2348

Yeah to be clear I agree that this is totally fine to do.

But I think we can safe us some work by not doing it as I don't see this doing anything beneficial either.

Maybe the PR is needed, and some code should also be updated.

As the containers/skopeo has already upgrade the github.com/containers/storage to v1.57.2, CI which required building skopeo binary will failed:

in the process of building skopeo, it will use go mod to replace the image/v5 in the vendor to the source code for containers/image, and containers/image seems use higher version of github.com/containers/storage lib:

fileutils.ReflinkOrCopy doesn't exist is github.com/containers/storage@v1.57.2.

for the older CI, it works because the required version in the containers/skopeo is v1.57.1, for the c/image lib, it requires v1.57.2-0.20250228100055-700b765b2111, v1.57.2 is higher than v1.57.1, so it will try to download and use the v1.57.2-0.20250228100055-700b765b2111 of c/storage. But if the skopeo upgrade c/storage to v1.57.2, go mod will think v1.57.2 is latest, and will not download v1.57.2-0.20250228100055-700b765b2111, so the ci of building skopeo binary will be failed.

during the process of finding the problem, the way that contains related lib or bin is a little bit heavy, sometimes chainable release will introduce extra work, maybe go workspace will be suitable for the current scenario.

for the older CI, it works because the required version in the containers/skopeo is v1.57.1, for the c/image lib, it requires v1.57.2-0.20250228100055-700b765b2111, v1.57.2 is higher than v1.57.1, so it will try to download and use the v1.57.2-0.20250228100055-700b765b2111 of c/storage. But if the skopeo upgrade c/storage to v1.57.2, go mod will think v1.57.2 is latest, and will not download v1.57.2-0.20250228100055-700b765b2111, so the ci of building skopeo binary will be failed.

We are aware of how this works, the tag here does not contribute to any solution though it makes things worse because now c/image 5.34.2 would be newer than its main branch as well.

The only way as I already have written above is to merge back each tag after the release into main

I am saying this because each of these releases puts extra burden on us, not just the extra release PR, the new version then triggers downgrades per go modules versions until we merge back branches which is annoying to deal with.
i.e. #2755 and containers/common#2348

And now containers/storage#2276 once that is merged c/storage@main will be update over 1.57.2

Although not needed from a Go compatibility perspective, before doing a release, like we are now for the RHEL Zero Day release, I very much prefer aligning the version numbers up and down the stack. It might be my OCD silliness, but I find it easier a year or more after a release to try and find what was where and what needs to bump. When I see c/storage 1.57.3 in Buildah, but 1.57.1 in image, I always end up digging more and second-guessing.

Yes a bit more grind for the team, but generally a very quick review. If we could push this through, I would appreciate it.

Let’s stay consistent, then.