go.{mod,sum}: bump runtime tools, spec deps to v1.3.0.

[klihub]

Bump OCI runtime tools and spec to v1.3.0.

[bart0sh]

/lgtm

[marquiz]

Thanks @klihub

LGTM

[elezar]

Thanks @klihub.

Is this something that we need to "backport" to the v1.0.0 spec, or are the changes on main such that we can go ahead and just release v1.0.1?

[klihub]

Thanks @klihub.

Is this something that we need to "backport" to the v1.0.0 spec, or are the changes on main such that we can go ahead and just release v1.0.1?

@elezar Hmm, I think we don't need to. The only reason for this dependency bump in CDI is to make the necessary OCI Spec bits for the pending Linux net device and RDT monitoring PRs (#269, #292) available to CDI, so we could kick those PRs forward at will.

Even in the (highly theoretical) case that some downstream CDI consumer wanted to make a new release with CDI 1.0.0 and opencontainer/runtime-spec 1.3.0, I'm not sure if we really were forced to do a backport. A locally unresolveable compilation failure would arise downstream if somehow because of us some golang package would be forced in with depending on pre-1.3.0 OCI Spec and someone in the compiled sources would reference LinuxPids.Limit in the Spec. Then we'd hit the int64 vs. *int64 snafu.

[AkihiroSuda]

Can we have a new git tag?

[klihub]

Can we have a new git tag?

@elezar @bart0sh @AkihiroSuda Before we do that it would be good to get #294 and #269 merged. And if we decide to go forward with #288, we could merge that, too.

[AkihiroSuda]

Can we have a new git tag?

@elezar @bart0sh @AkihiroSuda Before we do that it would be good to get #294 and #269 merged. And if we decide to go forward with #288, we could merge that, too.

@klihub Any chance to postpone unmerged PRs to vNextNext?

The release of containerd v2.2.1 is approaching, so it would be nice if we can have a tagged version of CDI (and NRI too: containerd/nri#243 (comment)) 🙏

[klihub]

Can we have a new git tag?

@elezar @bart0sh @AkihiroSuda Before we do that it would be good to get #294 and #269 merged. And if we decide to go forward with #288, we could merge that, too.

@klihub Any chance to postpone unmerged PRs to vNextNext?

The release of containerd v2.2.1 is approaching, so it would be nice if we can have a tagged version of CDI (and NRI too: containerd/nri#243 (comment)) 🙏

@AkihiroSuda We can definitely postpone merging pending functional PRs, but before tagging a 1.1.0 we need to fix a few inaccuracies that crept into the documentation, mostly related to recent changes for RDT. I have included the necessary changes in #269 (which was already approved for merging as such). We can either merge #269 with the additional changes or, if we want to keep the functional (Linux net device injection) changes out, we'll need to split out the doc adjusting changes to a new PR, then review and merge that separately.

@elezar WDYT ? Can you PTAL #269 and see if the doc fixes are good enough ?

[klihub]

@AkihiroSuda We merged what we could safely, fixed what we knew was off in the docs. And @elezar has already tagged the new v1.1.0 release. I'll file a PR to update containerd to use 1.1.0.

[AkihiroSuda]

Thanks!