New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cmd/go: should help users understand when a new GOOS or GOARCH breaks their build #28812

Open
theckman opened this Issue Nov 15, 2018 · 4 comments

Comments

Projects
None yet
4 participants
@theckman
Contributor

theckman commented Nov 15, 2018

We ran to an interesting issue today in the Go newbies channel on the Slack workspace, specifically around a user's build breaking in between Go v1.10.x and v1.11.x. I'm not sure if there's really a tenable solution here, but I thought it was worth starting a discussion with the Go authors.

This user upgraded from Go v1.10.x to Go v1.11.2 with no other changes to their code, and they were then met with build failures:

./swaguidist.go:15:38: undefined: swaggerUiBundleJs
./swaguidist.go:17:38: undefined: swaggerUiStandalonePresetJs

When the user tried to figure out what was wrong, they incorrectly asserted that because some of the files in the package were large the compiler was ignoring them. They reached out to the Slack workspace to see whether anyone was aware of such a limitation, but thankfully we happened to spot the files ending in *_js.go.

While I think it's ideal to expect everyone to read the release notes in their entirety, I don't think we'll ever get to that place. It makes me wonder if there're are any options available to us that would make these things a little more approachable and actionable (especially to newbies), versus something like a variable not defined error.

@theckman theckman changed the title from cmd/go: should help users understand when a new GOOS breaks their build to cmd/go: should help users understand when a new change breaks their build Nov 15, 2018

@theckman theckman changed the title from cmd/go: should help users understand when a new change breaks their build to cmd/go: should help users understand when a new Go language change breaks their build Nov 15, 2018

@ianlancetaylor ianlancetaylor added this to the Go1.12 milestone Nov 15, 2018

@ianlancetaylor

This comment has been minimized.

Contributor

ianlancetaylor commented Nov 15, 2018

Yes, this change in the handling of file names is an ongoing slow moving problem.

@cznic

This comment has been minimized.

Contributor

cznic commented Nov 15, 2018

FTR: This is not about a language change breaking builds. The build system is not the language.

@jimmyfrasche

This comment has been minimized.

Member

jimmyfrasche commented Nov 15, 2018

Should the mechanism introduced in #28221 be used to ignore build constraints that were not yet reserved by the language version recorded by the module?

@ianlancetaylor ianlancetaylor changed the title from cmd/go: should help users understand when a new Go language change breaks their build to cmd/go: should help users understand when a new GOOS or GOARCH breaks their build Nov 16, 2018

@ianlancetaylor

This comment has been minimized.

Contributor

ianlancetaylor commented Nov 16, 2018

@cznic Thanks, updated issue title.

@jimmyfrasche I worry that relying on that is likely to increase confusion rather than decrease it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment