This v0.4.0 tag is intended to show a scenario that is different from the example in #52296.
In this alternative, a different hypothetical foobar module has one package that only imports logrus, and a second optional package that also imports apparmor from containerd.
In other words, this is showing a different hypothetical package-level graph where apparmor is part of the module-level graph but apparmor is not in the package-level graph if a client only imports a subset of the foobar packages without directly or indirectly importing our optional package.
We are excluding the "bad" v1.7.1, v1.8.0, and v1.8.1 versions of logrus in our foobar go.mod, and as a result our foobar go.mod requires logrus v1.7.0.
The good news is that a new client of our foobar module that does not import our optional package now ends up with logrus v1.7.0, which was our desired outcome:
$ cat foobarclient.go
package foobarclient
import foobar "github.com/thepudds/test-go-mod-52296-a"
var F = foobar.Foobar$ cat go.mod
module test-go-mod-52296-a-client
go 1.18
require github.com/thepudds/test-go-mod-52296-a v0.4.0
require (
github.com/sirupsen/logrus v1.7.0 // indirect
golang.org/x/sys v0.0.0-20211216021012-1d35b9e2eb4e // indirect
)
One caveat however is if foobar was a library that went through these changes, a pre-existing client of our v0.3.0 would have already recorded the undesirable logrus v1.8.1 in its own go.mod, and the client would not magically have its version of logrus downgraded just by upgrading to our v0.4.0. If the client started by depending on our v.0.3.0 with a go.mod similar to:
$ cat go.mod
module test-go-mod-52296-a-client
go 1.18
require github.com/thepudds/test-go-mod-52296-a v0.3.0 // NOTE: v0.3.0 has a single package
require (
github.com/containerd/containerd v1.6.2 // indirect
github.com/sirupsen/logrus v1.8.1 // indirect
golang.org/x/sys v0.0.0-20211216021012-1d35b9e2eb4e // indirect
)
...and then if the client just upgrades to our v0.4.0 and runs go mod tidy, they end up with a go.mod similar to the following, which still depends on the undesirable logrus v1.8.1:
$ go get github.com/thepudds/test-go-mod-52296-a@v0.4.0
$ go mod tidy
$ cat go.mod
module test-go-mod-52296-a-client
go 1.18
require github.com/thepudds/test-go-mod-52296-a v0.4.0
require (
github.com/sirupsen/logrus v1.8.1 // indirect
github.com/stretchr/testify v1.7.0 // indirect
golang.org/x/sys v0.0.0-20211216021012-1d35b9e2eb4e // indirect
gopkg.in/yaml.v3 v3.0.0-20210107192922-496545a6307b // indirect
)