v0.7.0 is failing with "invalid Go version: 1.22" when running via golangci linter

[yurishkuro]

A bot tried to apply an upgrade of gofumpt and it started failing in the CI, raising panic in this line:

gofumpt/format/format.go

Line 99 in 86bffd6

panic(fmt.Sprintf("invalid Go version: %q", opts.LangVersion))

The code that it's trying to lint is built with 1.23 toolchain but with 1.22 compatibility

module github.com/jaegertracing/jaeger

go 1.22.0

toolchain go1.23.0

The setup works fine with gofumpt v0.6.0. It also works fine if the main toolchain is 1.22 (i.e. if we let Go toolchain download 1.23 itself).

[mvdan]

I think you need to raise this issue with golangci-lint. The panic does not appear to happen with the gofumpt binary at version v0.7.0, so it must be something that golangci-lint is doing in their custom code calling the gofumpt library. LangVersion: "1.22" is indeed invalid now, as we use and require https://pkg.go.dev/go/version as of the latest release, meaning that golangci-lint must specify something like LangVersion: "go1.22". cc @ldez

From a skim of golangci/golangci-lint@e24ef74 their code looks like it always adds the go prefix, but I'm not sure if you are somehow running a slightly older version of golangci-lint with the latest version of gofumpt. That wouldn't be something I can fix on my end either.

[mvdan]

Indeed - the PR you show is you updating gofumpt to the release we did three days ago, but golangci-lint's latest release is a week old, so the two latest releases are incompatible right now. The easiest next step is for golangci-lint to do a release.

I get that breaking changes can be annoying, but we used to accept a lax form of semver for Go versions, which was entirely incorrect - we must follow Go versions to get the right semantics, for example 1.22 versus 1.22.0 and 1.22rc1, which does not follow semver. Trying to support both semver and Go versions at the same time seemed like a bad idea given that they compare differently between seemingly equivalent versions.

[ldez]

Hello, I already fixed the problem 3 days ago golangci/golangci-lint#4922

@mvdan You can close this issue.

[ldez]

@yurishkuro you should not update golangci-lint dependencies outside of the official version of golangci-lint.

[mvdan]

Yes, the issue is with the release times, see my last comment :)

Note that the change here happened over a month ago, so I didn't exactly push it at the last minute - there should have been some warning. 88a300b

[mvdan]

I'll leave this issue open for now because, from past experience, users will keep opening issues here until golangci-lint does another release. I'd rather keep this open for another week than have to close another two or three issues as duplicates.

[ldez]

Note that the change here happened over a month ago, so I didn't exactly push it at the last minute - there should have been some warning.

We are aware of changes only when a release happens, I cannot follow all the linter changes.
But I fixed the problem immediately when the release happened.

[mvdan]

Yep, understandable. FWIW I keep breaking changes to a minimum where I can. This was a rare exception as I explained above.

[ldez]

From what I have read, now the official version has a better semver style (except for rc).

Go 1.21 introduces a small change to the numbering of releases. In the past, we used Go 1.N to refer to both the overall Go language version and release family as well as the first release in that family.
https://tip.golang.org/doc/go1.21

This means that go1.21 is now a "release family" and go1.21.0 is a version.
And there are no tags/versions go1.22 or go1.23.

The syntax ‘1.N’ is called a “language version”.
...
For example, 1.21 < 1.21rc1 < 1.21rc2 < 1.21.0 < 1.21.1 < 1.21.2.
...
Before Go 1.21, the initial release of a Go toolchain was version 1.N, not 1.N.0, so for N < 21, the ordering is adjusted to place 1.N after the release candidates.
https://go.dev/doc/toolchain#version

I also note that the vocabulary is not the same across the doc but I think we can get the idea.

[mvdan]

Yep, correct. Just note that Go versioning is different from semver in that Semver dictates v1.22-rc.1 < v1.22 == v1.22.0, but Go versioning dictates go1.22 < go1.22rc1 < go1.22.0, because as you say, go1.22 is a "major version family".

[ldez]

but Go versioning dictates go1.22 < go1.22rc1 < go1.22.0

But as go1.22 is not a version this comparison cannot happen now, it's only a thing for Go < 1.22.
Now go1.22 == go1.22rc1 and go1.22 == go1.22.0, etc.

[mvdan]

Well, go1.22 and go1.23 will never be releases anymore, but they are still valid Go versions which can be used in go.mod files, via the go/version API, with gofumpt, etc. So, still, go1.22 != go1.22.0 - they mean different things.

[ldez]

but they are still valid Go versions which can be used in go.mod files

It seems not fully true: golang/go#65568 (comment)

go-acme/lego#2241 (comment)

Code QL, when using at least go1.21, reports a warning:

So yes you can still use it but some problems can happen because of that, so it is not really usable inside go.mod expect if you also define toolchain.

[ldez]

The vocabulary across the doc is a problem:

At go 1.21 or higher:

• The go line declares a required minimum version of Go to use with this module.
• ...

https://go.dev/ref/mod#go-mod-file-go

Go versions

Released versions of Go use the version syntax ‘1.N.P’, denoting the Pth release of Go 1.N. The initial release is 1.N.0, like in ‘1.21.0’. Later releases like 1.N.9 are often referred to as patch releases.

Go 1.N release candidates, which are issued before 1.N.0, use the version syntax ‘1.NrcR’. The first release candidate for Go 1.N has version 1.Nrc1, like in 1.23rc1.

The syntax ‘1.N’ is called a “language version”. It denotes the overall family of Go releases implementing that version of the Go language and standard library.

The language version for a Go version is the result of truncating everything after the N: 1.21, 1.21rc2, and 1.21.3 all implement language version 1.21.
https://go.dev/doc/toolchain#version

If I just read those docs, I can think that the go directive should theoretically declare a version (the minimum version, so 1.N.P) and not a "release family"/"language version".

The doc uses the terms "language version", "release family", "version syntax", "version", "release", and "released versions" to talk about the same topic, this creates confusion on where each element can be used.

[ldez]

I'll leave this issue open for now because, from past experience, users will keep opening issues here until golangci-lint does another release.

I will create a release tomorrow/today at about 8 pm UTC.

[mvdan]

https://github.com/golangci/golangci-lint/releases/tag/v1.60.2 happened four days ago as promised - closing this.

[yurishkuro]

Thank you all for swift resolution! 🚀