You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There are some places in x/build that try to determine a Go version of a Go commit in order to make some decisions (what builders should be run, etc.). So far we've been relying on heuristics to approximate the answer. There's some information in the name of the branch itself. For example, "release-branch.go1.15" can be parsed so we know that any commit on it is Go 1.15. If we know the latest Go release is Go 1.15.x, then we can guess that
a commit on "master" or "dev.link" branch is likely a development version of Go 1.(15+1).
By now, there is a package internal/goversion in the Go tree that tracks the Go version precisely. It's possible to create a service that processes new Git commits as they're pushed and do the work needed to determine the precise Go version of that Git commit (for example, by reading the git tree), then serve answers quickly.
This is an issue for tracking progress made towards having a service that's able to answer such "commit hash -> precise Go version" queries. (Including things like agreeing we want to do this, describing a design, etc.)
The vast majority of the time, when Go 1.X (or Go 1.X.Y) is the latest
supported Go release, non-release branches are used for developing
the next Go 1.(X+1) version and not the same Go 1.X version.
Adjust the imperfect heuristic used to determine the Go version from
the branch name by taking this into account.
Make the output from the TestFindTryWork test easier to read,
as it's expensive to add test coverage for this change elsewhere.
Run-TryBot: Dmitri Shuralyov <email@example.com>
TryBot-Result: Go Bot <firstname.lastname@example.org>
Reviewed-by: Carlos Amedee <email@example.com>
Reviewed-by: Alexander Rakoczy <firstname.lastname@example.org>
Trust: Dmitri Shuralyov <email@example.com>