Disable go version updates by default

[harryzcy]

How are you running Renovate?

Mend Renovate hosted app on github.com

If you're self-hosting Renovate, tell us what version of Renovate you run.

No response

Please select which platform you are using if self-hosting.

No response

If you're self-hosting Renovate, tell us what version of the platform you run.

No response

Was this something which used to work for you, and then stopped?

It used to work, and then stopped

Describe the bug

A recent change #16541 cause renovate to update go version in go.mod by default, which shouldn't be the case.

Syntax
    go minimum-go-version

minimum-go-version
    The minimum version of Go required to compile packages in this module.

Per go.mod file reference, version should be the minimum version supported, not an update-to-date one. So the feature to update go version should be disabled by default, and only enabled via configurations.

Relevant debug logs

No response

Have you created a minimal reproduction repository?

No reproduction repository

[rarkins]

I understand your position but this can also lead to regular upgrades failing whenever any dependency needs a newer version of go too. In other words if you stay on an old minimum version of go forever you'll eventually get stuck behind on most dependencies.

[nemunaire]

I support the request of @harryzcy. The current implementation is really annoying and creates lots of issues inherent to the way go.mod evolve.

There are many side-effects introduced regularly by newer go releases on how the go.mod is treated. For example, I have many repository with go 1.10, go 1.13, go 1.16, ... With the introduction of this feature, all my repositories fails to compile with errors likes these:

go: inconsistent vendoring in /drone/src:
	github.com/nfnt/resize@v0.0.0-20180221191011-83c6a9932646: is explicitly required in go.mod, but not marked as explicit in vendor/modules.txt

	To ignore the vendor directory, use -mod=readonly or -mod=mod.
	To sync the vendor directory, run:
		go mod vendor

as the format of go.mod changes regularly and can't be considered stable for now.

So I need to do manually run go mod commands in this case to update the format, but it's difficult to know what to expect in future releases. If the format changes again in 1.19, it will not have helped anyone and will have caused a lot of pull request noise for nothing.

As the primary goal of the go x.xx instruction is to hard block on a given release, it seems acceptable to manually upgrade it only when a dependency requires it and not automatically by default. Having the choice to enable this beta implementation can be interesting though.

On some other repositories, that make use of gin-gonic/gin, I decided on some project to make the go 1.18 upgrade (as gin new releases uses any feature), but on other project, that I want to be compatible with older go releases, I make the choice to continue to use the gin branch that does not use go 1.18 features.

Moreover, it's true the introduction of the generics in the 1.18 release decided a lot of project to switch to this release, but from my point of view it's pretty rare to have so interesting new features and projects are rather used to stay on a given go release forever.

So the go version update introduced does more harm than good to the community, because even projects that don't require a new release of go will fail to compile with previous go releases just because renovatebot choose to make the update, by default, even if it's not required.

Either the functionality should be better implemented (by updating the go x.xx only when a dependency needs it), or it should be considered as beta and disabled by default.

[viceice]

i don't agree, we need to check which command needs to be run to update the sum file, so the update works like any other go mod update.

you can always disable those updates yourself or require dashboard approval to have visibility.

[nemunaire]

If this can be acceptable for an end user project, as the only implication is that this project requires a recent compiler, what about libraries?

With this option enabled by default, unconscious developers using renovatebot will force others end user projects (using renovatebot or not) to update their go.mod to a more recent version, even if no one use or require a recent go feature.

Of course this feature need to be fixed in renovatebot, but this is not the point here: go x.xx should be increased only if it is required.

There is no security implication to not update this value, it only reduces compatibility artificially.

[viceice]

it was a community feature request/ implementation to support updating go.
so we currently don't plan to change that.

you can always close / ignore those PR's. or disable those updates via config.

we can maybe provide a helper preset to easily disable those updates.

[nemunaire]

It's not the feature that is criticized, but its activation by default.

As @rarkins mention, people need that to perform usual modules update smoothly. And I'll be glad not to have to manually change my go x.xx anymore in such case. But in its current state, this feature is not finished and ruin the compatibility.

We ask that it be disabled by default, while a better solution is implemented. So people that need this can activate it, but knowing the implications.

I can certainly disabled it on my repos, but I don't want to create thousand issues requesting to revert such changes, on dependencies I don't own, when this is unneeded. Just because the dev merge such PR without calculating the implications regarding the compatibility.

The fact is the vast majority of module update can be performed without updating the go x.xx instruction. Sometime a dependency uses a new feature, so in that case renovatebot should update go x.xx at the same time the dependency update is pulled. But this can't be the default case otherwise. The Go team doesn't advertise to update the go x.xx instruction without the need to do so ("The minimum version of Go required to compile packages in this module"), on purpose.

[rarkins]

Please provide links/references for your last sentence so we can assess.

[nemunaire]

This is what @harryzcy writes in first post: https://go.dev/doc/modules/gomod-ref#go-syntax

Syntax

go minimum-go-version

minimum-go-version
: The minimum version of Go required to compile packages in this module.

minimum version is what we ask for. latest version is what renovatebot performs currently.

In a project using go 1.15, if one deps required go 1.18, then we should update our go x.xx to go 1.18, but if a new go version is released, updating the version is not necessary as long as:

• our code doesn't use any new feature or
• any deps doesn't use any new feature.

In a project using go 1.15, with all deps requiring go 1.15 or lower, then nothing should happen. As this really is the minimum version of Go required to compile.

[rarkins]

That's purely syntax, not any justification or argument. It does not alone imply that you should avoid updating it

[rarkins]

Relevant: https://endoflife.date/go

https://go.dev/doc/devel/release#policy

[nemunaire]

Will you accept a pull request implementing a smarter go x.xx, to be used by default instead of the current feature, based on the max(max deps required version,current module version)?

[nemunaire]

Perhaps you should consider this example: go 1.19 will be out next month. All projects (end user project and modules on which end user projects depends) will move to a go 1.19 instruction in their go.mod due to this feature.

But in august, who will have a go 1.19 compiler? Ubuntu users will be on 1.18 until Ubuntu 22.10 in October (and some people prefer to stay on LTS, so on go 1.18 for the next 2 years), so even if they don't need the new features, you'll impose them to download an install a new compiler without any reason... Same for Debian, Alpine, ...

And your link shows that go 1.17 is still officially supported, but this renovatebot feature forces all modules/libraries to use 1.18. How can someone which is still on 1.17.12 use a github module managed by renovatebot?

Also you should consider RedHat Enterprise users, they have an old go compilers in their repository (no more supported officially), some people develops for those users and fix things. They also need their dependency to be compatible with the minimum version.