module go version

[ldez]

It's possible for you to downgrade the version inside your go.mod to go1.20?

the new way to handle the module and go version is strict.

https://github.com/golangci/golangci-lint/actions/runs/5893637045/job/15985603630?pr=4023

https://go.dev/blog/toolchain

golangci/golangci-lint#4023

[Antonboom]

@ldez Hi! Done.

It's my bad – these linters are simple and do not require 1.21 API.
But what about the new ones?

[ldez]

But what about the new ones?

For now, I will just ask to downgrade but the new Go version management system is really viral.

The Go version inside the go.mod should be set to the real minimal required version.
But as the community has the habit to update the Go mod version to the latest version every time a new Go version is happening, I think it will force everyone to use the latest version.
It will be an "evergreen" Go world 😄

[Antonboom]

What are the rules for updating a go.mod in golangci-lint? If the new linter really requires modern Go (for example, slices and maps, which are gaining popularity now), then you will have to update the golangci-lint module

[ldez]

What are the rules for updating a go.mod in golangci-lint?

We will use go1.20 until we have no choice.

Currently, we build golangci-lint with go1.21 to be able to support go1.21 but this version, compiled with go1.21, works for projects before go1.21.
This is nothing new, we've always done this.

When we will be forced to use go1.21, only the projects that use golangci-lint with the "tools" pattern and a Go version before go1.21 will be impacted.

The real difference: before a project that uses a module with a more recent version of Go, but the module doesn't use specific things related to this recent version of Go, was able to build with an older version.
Now the project will be forced to build with the newer version even if the module doesn't really require this new version.

go inside go.mod is now a real minimum version like the dependency versions.