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
{{ message }}
This repository was archived by the owner on Mar 23, 2021. It is now read-only.
The gobin cache for a given binary isn't invalidated when the version of Go has changed. In practice, this leads to issues when the compilation behavior differs.
As a concrete example, module builds of swagger-go @ 0.20.1 with go 1.12 results in a perfectly fine working binary whereas go 1.13 creates a binary that throws stack traces when trying to generate models. Due to gobin's current caching behavior, one may be lead to falsely believe that the go 1.13 toolchain works fine for building the 0.20.1 version of swagger-go.
The text was updated successfully, but these errors were encountered:
I just ran into this issue as well. I suspect a simple fix here is to just change the gobinCache location to include runtime.Version() in its path (or alternatively use the version reported by go version). If that is an acceptable fix, I can probably send a PR..
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
The gobin cache for a given binary isn't invalidated when the version of Go has changed. In practice, this leads to issues when the compilation behavior differs.
As a concrete example, module builds of swagger-go @ 0.20.1 with go 1.12 results in a perfectly fine working binary whereas go 1.13 creates a binary that throws stack traces when trying to generate models. Due to gobin's current caching behavior, one may be lead to falsely believe that the go 1.13 toolchain works fine for building the 0.20.1 version of swagger-go.
The text was updated successfully, but these errors were encountered: