[skybrian]

As I understand it, that's true in the simple case. If you have `my_app -> foo -> bar` then there's only one path to bar, and you only get a new bar when you upgrade foo.

It's more complicated in general, with diamond dependencies. There needs to be a chain of module updates between you and foo, with the minimum case being a chain of length one where you specify the version of foo directly.

So, people do need to pay attention to security patch announcements. But popular modules, at least, are likely to be get updated relatively quickly, because only one side of a diamond dependency needs to notice and do a release.

[coder543]

> As I understand it, that's true in the simple case. If you have `my_app -> foo -> bar` then there's only one path to bar, and you only get a new bar when you upgrade foo.

This is not correct. You can update bar independent of foo directly from the top-level go.mod file in your project.

[skybrian]

Yes, you can do that by adding a direct dependency on foo. I started by talking about when there isn't a direct dependency on foo.

I explicitly talked about having a direct dependency at the end of the second paragraph.

[coder543]

I'm not talking about direct dependencies. Direct and indirect are all listed in the go.mod file. If they aren't listed there, then they aren't in your final binary. If you delete indirect dependencies from the top-level go.mod, your project will fail to compile.