Raised a PoC PR, and it passed all the checks. If it looks good to you, I can raise a PR in this repository. I will also update the README.md to indicate what's supported.
Each major Go release is supported until there are two newer major releases.
As a result, unless under some special circumstances, I feel that it does not make much sense to support versions that are not even supported by official Go team.
../../../golang.org/x/tools/internal/typeparams/normalize.go:162:17: u.EmbeddedType undefined (type *types.Interface has no field or method EmbeddedType)
I also noticed that we have golang.org/x/tools v0.0.0-20191109212701-97ad0ed33101 in our go.mod, and in that version, the whole typeparams directory does not even exist. From the line number in the error message above, the build job seems to use the latest version instead of the one specified in go.mod, and why is that?
The Go version is 1.10 in the job, and modules was introduced in 1.11, and I suspect that the go get ./... simply downloads the latest version because it just does not understand go.mod.
At this timepoint, I figured that maybe it makes more sense to support the latest releases (i.e., 1.17 and so on) instead of making effort to maintain releases that are too old.
TL;DR
Raised a PoC PR, and it passed all the checks. If it looks good to you, I can raise a PR in this repository. I will also update the
README.mdto indicate what's supported.Why
From Go's release policy:
As a result, unless under some special circumstances, I feel that it does not make much sense to support versions that are not even supported by official Go team.
Context
As of now, tests are failing with the following error message:
That is because in Go1.10,
type *types.Interface has no field or method EmbeddedType.I also noticed that we have
golang.org/x/tools v0.0.0-20191109212701-97ad0ed33101in ourgo.mod, and in that version, the wholetypeparamsdirectory does not even exist. From the line number in the error message above, the build job seems to use the latest version instead of the one specified ingo.mod, and why is that?The Go version is 1.10 in the job, and modules was introduced in 1.11, and I suspect that the
go get ./...simply downloads the latest version because it just does not understandgo.mod.At this timepoint, I figured that maybe it makes more sense to support the latest releases (i.e., 1.17 and so on) instead of making effort to maintain releases that are too old.