Stop bumping go directive unless necessitated by other dependencies

[kaovilai]

This PR https://github.com/containers/image/pull/2601/files for example did not need to bump go directive.

The minimum go required for that PR dependency bump is

❯ go mod graph | grep 'github.com/sigstore/sigstore' | grep go@
github.com/sigstore/sigstore@v1.8.11 go@1.22.0

A more acceptable minimum is one that is unfortunate but required by other modules.

❯ go mod graph | grep go@1.22.6  
github.com/sigstore/fulcio@v1.6.4 go@1.22.6

This repo by itself should not be enforcing minimum on other repositories importing it. Stop spreading "minimum virus"

toolchain version used will be defined outside of go.mod ideally, such as by installing a newer compatible go toolchain to ci/cd/development env.

Failing that, toolchain directive should be used instead of go directive for bumping versions to not cascade minimum versions to importing dependencies.

toolchain directive, in contrast to the go directive, applies only to the current module (the one defined by the go.mod file). It suggests the toolchain to be used when in that very module, and doesn't propagate to other modules.

High profile repos that have removed/reduced minimum go patch version per user requests

• deps: Remove Go minor version from go.mods grpc/grpc-go#7831 motivation

Being proactive to prevent following from reoccuring

• deps: Remove Go patch version from go.mods kopia/kopia#4292
• Do not set minimum go toolchain version in release branches. vmware-tanzu/velero#8397
• Bump github.com/vmware-tanzu/velero from 1.14.0 to 1.15.0 kubevirt/kubevirt-velero-plugin#292 (comment)

[kaovilai]

/cc @mtrmac

[mtrmac]

Thanks for reaching out.

This PR https://github.com/containers/image/pull/2601/files for example did not need to bump go directive.

That PR did need to bump the go directive; the PR was filed by a bot, and the bot documents the rationale.

The minimum go required for that PR dependency bump is

❯ go mod graph | grep 'github.com/sigstore/sigstore' | grep go@
github.com/sigstore/sigstore@v1.8.11 go@1.22.0

That’s true as of v1.8.11, not as of v1.8.10. ….11 decreased the required Go version.

This repo by itself should not be enforcing minimum on other repositories importing it. Stop spreading "minimum virus"

This is an intentional property of the Go module / versioning system, and, for better or worse, no individual repo can stop that from happening. It would take a coordinated action from way too many actors in the ecosystem to give users back the desired control.

I think the best bet would be to convince Go upstream to change the design, and the chances seem low to me.

Failing that, I think users need to be ready to accept the need to update to a new Go 1.X.Y version on short notice. (We do try hard to delay updates to 1.X versions, because those tend to require more migration. But that’s still a trade-off, WRT making it possible to fix vulnerabilities in dependencies quickly.)

Failing that, toolchain directive should be used instead of go directive for bumping versions to not cascade minimum versions to importing dependencies.

When dependencies of c/image update the go dependency, we don’t have a choice; the tooling will enforce the minimum.

---

In this particular case as of this moment, we might be able to go back to 1.22.6 (I would accept a PR for that but I’m not going to file one myself) — but, I think that longer-term this is mostly futile and, sadly, users of Go-written software ultimately need to be ready to update the toolchain.

[kaovilai]

Yes the tooling will enforce the minimum for other deps of c/image. Except - some repos do actually bump go directive for forcing GitHub actions setup-go to select version based on go.mod. the proper thing to use there is toolchain directive not go directive.

Just adding cautionary tales.

There are enough coordinated effort out there that without changes to golang a significant number of projects can ward off minimum patch version of golang.