This code does enforce the version currently declared by the go directive.
Which in turn will prevent any dependency upgrade to succeed that requires even a higher minor version of go.

go 1.23.0

config.constraints.go 1.23 (or GOTOOLCHAIN="local")
installed toolchain go1.23.1

required by dependency: go1.23.7

enforced by constraint: go1.23.0

Wasn't there agreement that this is undesired?

that's why I add this: https://github.com/renovatebot/renovate/pull/34779/files#diff-fd367c04a5c8c9b0dcbe22bb60da84f2b674ce21dadc840799ab1c2dd9b1a251R217-R221

we will execute this command: https://github.com/renovatebot/renovate/pull/34779/files#diff-4c37b8edc62aa49295d264c221717bd0361ccff0a791d4327f4421a0ea23521fR2355

go will check it for us

https://github.com/renovatebot/renovate/pull/34779/files#diff-4c37b8edc62aa49295d264c221717bd0361ccff0a791d4327f4421a0ea23521fR2214

Consider x/crypto would specify go1.23.7 in it's go.mod

[email protected] would not allow that ...
And users can not control that behavior in renovate. They would explicitly need to bump go before that. Why not allow the bump in same PR?

IMO the language version should have more priority than library version. Users can always enable updating go directive, but they can't suppress updating go directive caused by library if they want, therefore is this PR

The question is what a sane default is:

1. allow automated go version bumping that is supported by local toolchain when dependency requires that (have PRs that can be merged, toolchain always latest, current state of affairs)
2. avoid that (have PRs that break), enforce users to maintain their go directive separately
3. allow users to choose from 1) and 2) - e.g. if config.constraints.go is set, use strategy 1) for allowing updates within the constrained minor only

Who would be able to take such decision @viceice ?

..., but they can't suppress updating go directive caused by library if they want

That is only the case for auto-merges of PRs. Otherwise users can transparently review and close unwanted PRs.

Please also consider that the changes currently WILL ALLOW go directive bumping. Here is the observation:

go.mod is at 1.22.0

go get -t ./... toolchain@none [email protected] github.com/someorg/[email protected]
go: github.com/someorg/[email protected] requires go >= 1.22.2; switching to go1.23.8
go: github.com/someorg/[email protected] requires [email protected], not [email protected]

go.mod is at 1.22

go get -t ./... toolchain@none [email protected] github.com/someorg/[email protected]
go: github.com/someorg/[email protected] requires go >= 1.22.2; switching to go1.23.8
go: upgraded go 1.22.0 => 1.22.12

go.mod is now at 1.22.12

And that is if GOTOOLCHAIN is "auto". On "local" with a 1.22.0 toolchain, we get no switching:

go get -t ./... toolchain@none [email protected] github.com/someorg/[email protected]
go: github.com/someorg/[email protected] requires [email protected], not [email protected]

Thanks, I don't know this case.

A workaround would be using go 1.23 instead of go 1.23.0 in go mod, but that requires user to change their code ...

A better solution would be disabling go version switching and pick 1.23.0 when it has go 1.23 directive 😅

The question is what a sane default is:

1. allow automated go version bumping that is supported by local toolchain when dependency requires that (have PRs that can be merged, toolchain always latest, current state of affairs)
2. avoid that (have PRs that break), enforce users to maintain their go directive separately
3. allow users to choose from 1) and 2) - e.g. if config.constraints.go is set, use strategy 1) for allowing updates within the constrained minor only

Who would be able to take such decision @viceice ?

IMO, if users want renovate to touch go version, they can manually enable it.

So renovate will update the go directive to expected version based on user config.

If they group go directive with packages, they get one working PR.

And if they have seprated PRs for go direcive and package, they can still get a working PR for package after they merge the PR for go directive.

But I'm not opposed to a new config that let go command updating go directive, it would very easy to add such feature. we just don't push anything into extraGetArguments.

For example

const preserveGoDirective = config.preserveGoDirectives ?? 'enabled';
if (
  preserveGoDirective !== 'enabled' &&
  semver.satisfies(goMod.minimalGoVersion, '>=1.21.0')
) {
  extraGetArguments.push(`toolchain@${goMod.toolchainDirective ?? 'none'}`);
  extraGetArguments.push(`go@${goMod.goDirective}`);

  ...
}

But it should be done in a seprated PR.