Cut next release (probably v1.43.1)

[saschagrunert]

We have a huge amount of commits in the main branch from the previous release: v1.43.0...main

Are we happy to cut a next version yet?

[rhatdan]

Whenever you want one, I am fine with cutting it.

[saschagrunert]

Thank you! Looking forward to the new release being part of CRI-O. :)

[rhatdan]

https://github.com/containers/storage/releases/tag/v1.44.0

[p0pr0ck5]

Hello,

This latest release (1.44.0) contains a breaking change in the API. Should this project move to a v2? It's not possible to compile applications that have github.com/containers/podman/v4 as a dependency when the project go.mod includes github.com/containers/[email protected], due to this change. Example output (I can provide more details if needed):

# github.com/containers/podman/v4/pkg/rootless
../../../go/pkg/mod/github.com/containers/podman/[email protected]/pkg/rootless/rootless.go:43:18: pidFileLock.Locked undefined (type lockfile.Locker has no field or method Locked)

This isn't a problem for the most recent tag of github.com/containers/podman, since it pins to github.com/containers/[email protected] (https://github.com/containers/podman/blob/v4.3.1/go.mod#L20), but I found that when running go get -u on a project that uses github.com/containers/podman, github.com/containers/storage was upgraded to v1.44.0 and caused a compile failure. I had to manually change the indirect dependency pin to github.com/containers/[email protected] in my project go.mod.

If github.com/containers/storage is following semantic versioning, should the breaking API change result in a separate v2 tag?

[chenrui333]

yeah, I have the similar question, as there is a breaking change in the API, it might be good to release as a major version update.

[rhatdan]

We are using this version of container/storage in main branch right now. Are you saying Podman 4.4 has modified to use this API.