@mtrmac PTAL, especially the second commit. The version got set in the main branch to 5.34.1-dev prior. I think creating 5.34.0 at this point will be OK, but I'm a little concerned about projects that may have vendored from main in the past few weeks. Go vendoring sometimes gets wonky.

The version from the file doe snot matter a bit to the go vendoring so it makes no difference. go vendoring works based of the tag names.

So bumping to 5.34.0 seems like the correct things to do, skipping a .0 would possibly confuse quite a few folks.

@mtrmac PTAL, especially the second commit. The version got set in the main branch to 5.34.1-dev prior.

I’m sorry, that’s my mistake, I should have caught that while creating #2691.

I think creating 5.34.0 at this point will be OK

I agree.

As Paul says, this is invisible to Go tools. It might show up in some version information, e.g. User-Agent strings, that could be interpreted as a post-5.34.0 version. I’m worried very little about that: The important part is the -dev suffix, which tells us that we need to actually ask for the precise commit — and once we do, that’s precise by itself.

Per a Slack conversation, should I merge this immediately, or do you want some variant of containers/storage#2230 be tagged first?

It was found that a PR was needed in c/storage. We are working on updating the 1.57 branch there, and will revendor here after that is done.

I've updated this to c/storage 1.57.1 and this can now be merged after happy tests and review. ATM, Skopeo Test is failing on what looks to be a network error.