Should we have done a release of ttrpc before the nri release? Was this a requirement for nri to work? https://github.com/containerd/nri/blob/v0.6.0/go.mod#L6

I see it was updated in containerd/nri@f600cf6 along with other dependencies.

Mostly wondering what the minimal requirement is for nri - for libraries, we should strive to stick to Go modules "MVS" (minimum version selection), and leave it to consumers to pick versions above that where needed (e.g. the golang.org/x/sys version was originally put at v0.1.0 as the module did not depend on anything newer than that).

The last non-bugfix commit in NRI (45b9e3f1437f) was to allow otel trace context propagation over ttrpc (for which I am about to file another PR). For that 40f227ddbb9e in ttrpc would be enough, since everything above that are depdendabot version bumps.

I guess that means that ideally we should have tagged a new ttrpc release at that sha1, right ? In general, we've not been very eager with tagging ttrpc in the past, so we tend to have sha1-exact requirements for ttrpc in NRI.

Yeah, maybe it's not a "big deal" in this case;

• containerd 1.6 (LTS) is on v0.1.1 (and where needed, we could do a v0.1.2); https://github.com/containerd/containerd/blob/v1.6.28/go.mod#L20
• containerd 1.6 is on v0.4.0 (so we could have a v0.4.1); https://github.com/containerd/containerd/blob/v1.7.13/go.mod#L21

But the thing I try to keep in mind is that updating the versions in library modules means (in a Go modules world); this is the absolute minimal version that can be used. And that every consumer of the module MUST update all those dependencies to at least the given version.

When setting those minimum versions too optimistic "let's use latest!" that can have a ripple effect, which can be problematic if those are common dependencies, and while nri (in this case) itself may not be affected by other changes in those dependency-modules (because it may not be using those other parts), consumers of nri (or containerd, or some other code depending on containerd) could be affected, and now being forced to update those dependencies (and so on).

So for library modules, I try to keep required versions as low as possible; doing so allows consumers (such as containerd) to pick the version they need, and having those versions "low" also keeps the module more flexible (e.g. if there's a need, we can update the version in the 1.7 release branches if there's a fix in nri, without that resulting in all other dependencies to also have to be updated).

w.r.t. the tag for ttrpc; it's good practice to (where reasonably possible) only use tagged versions in (non-pre-)releases.

Technically, v1.2.3-0.20231030150553-baadfd8e7956 is an unreleased (and thus unstable version) of a dependency. Changes can be made before the next release, and with Go modules requiring SemVer, the version of that release is not yet known until it's released (you don't know versions ahead of time, because the changes in code dictate wheter the "major", "minor", or "patch" version must be updated, so it could become v1.2.3, v1.3.0 or if there's breaking changes, it could even become v2.0.0). This can be a risk. In this case we "control" the module, so we have more influence over what happens, but I know that distro packagers in most cases do not use unreleased versions, so will pick v1.2.2 instead (NOT the version we specified), which has led to packages being broken (sometimes in subtle ways that do not immediately surface).

Yeah, maybe it's not a "big deal" in this case;

• containerd 1.6 (LTS) is on v0.1.1 (and where needed, we could do a v0.1.2); https://github.com/containerd/containerd/blob/v1.6.28/go.mod#L20
• containerd 1.6 is on v0.4.0 (so we could have a v0.4.1); https://github.com/containerd/containerd/blob/v1.7.13/go.mod#L21

But the thing I try to keep in mind is that updating the versions in library modules means (in a Go modules world); this is the absolute minimal version that can be used. And that every consumer of the module MUST update all those dependencies to at least the given version.

When setting those minimum versions too optimistic "let's use latest!" that can have a ripple effect, which can be problematic if those are common dependencies, and while nri (in this case) itself may not be affected by other changes in those dependency-modules (because it may not be using those other parts), consumers of nri (or containerd, or some other code depending on containerd) could be affected, and now being forced to update those dependencies (and so on).

So for library modules, I try to keep required versions as low as possible; doing so allows consumers (such as containerd) to pick the version they need, and having those versions "low" also keeps the module more flexible (e.g. if there's a need, we can update the version in the 1.7 release branches if there's a fix in nri, without that resulting in all other dependencies to also have to be updated).

w.r.t. the tag for ttrpc; it's good practice to (where reasonably possible) only use tagged versions in (non-pre-)releases.

Technically, v1.2.3-0.20231030150553-baadfd8e7956 is an unreleased (and thus unstable version) of a dependency. Changes can be made before the next release, and with Go modules requiring SemVer, the version of that release is not yet known until it's released (you don't know versions ahead of time, because the changes in code dictate wheter the "major", "minor", or "patch" version must be updated, so it could become v1.2.3, v1.3.0 or if there's breaking changes, it could even become v2.0.0). This can be a risk. In this case we "control" the module, so we have more influence over what happens, but I know that distro packagers in most cases do not use unreleased versions, so will pick v1.2.2 instead (NOT the version we specified), which has led to packages being broken (sometimes in subtle ways that do not immediately surface).

@thaJeztah That's nice recap/reminder about module dependency management. And I have to say that I've probably failed constantly/consistently on that front, thoughtlessly giving in to the "let's just use the latest" urge. At least I have never consciously considered these aspects in such an explicitly articulated manner.

Hmm, and maybe already that baad sha1-prefix in the offending v1.2.3-0.20231030150553-baadfd8e7956 dependency was the universe trying to tell me something but I was just not listening...

So would this be a decent corrective course of actions ?

1. tag ttrpc baadfd8e7956 as v1.3.0 (v1.2.2..40f227ddbb9e contains backward-compatible changes/additions to the public API)
2. update NRI's ttrpc dependency to v1.3.0 and tag it as v0.6.1 (only dependency changes)
3. update this PR to require NRI v0.6.1 and ttrpc v1.3.0

WDYT ?

I saw v1.2.3 was tagged, and opened containerd/nri#71

Interesting, I thought that semver-compatible versioning would have required us to bump the minor version number (going to 1.3.0), since we've added new public functions since 1.2.2.

Yes, agreed, I think that should've been v1.3.0, but I guess it's released, so not sure if that can still be fixed, other than doing a v1.2.4 with that change reverted (possibly retracting v1.2.3), and a v1.3.0 after that 😬 (cc @dmcgowan)

No, I think we shouldn't do that. The cat's out of the bag. I just asked to make sure my impression was right.