Skip to content
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: build tags for beta and RC builds clarification #26458

dlsniper opened this issue Jul 19, 2018 · 4 comments


None yet
4 participants
Copy link

commented Jul 19, 2018


I would like to get some clarification about how the build tags for Go versions work.

For example, we have now Go 1.11 Beta 1, which I would expect to use the go1.11beta1 build tag and, when Go 1.11 RC 1 is released, I would expect to have go1.11rc1 used. When Go 1.11 is released, I would expect to see go1.11 flag working.

However, currently Go 1.11 Beta 1 seems to use go1.11 as build tag. Normally, I would expect this to be a bug, since go1.11 > go1.11beta1 regarding release versions.

Have I missed something from the way build tags should work? Or if this is undocumented/unwritten can we please get some more official information on it?

Thank you.


This comment has been minimized.

Copy link

commented Jul 19, 2018

The go1.11 tag was added and made the current tag in 8de2f60, which was submitted very early in the 1.11 cycle. This happens at the start of every cycle, I believe.

I've always understood the reasoning to be the API versioning, i.e. what you can find in files like api/go1.11.txt. That's why I presume that build tags like go1.11beta1 don't exist, just like go1.10.3 doesn't exist either.

I think you're right that the documentation is a bit lacking, though. From

  • "go1.11", from Go version 1.11 onward

I think we should explicitly say something like "including 1.11 betas and RCs". Although if this is hidden in, I'm not sure how useful it would be for everyday users downloading 1.11 betas.

@mvdan mvdan added the Documentation label Jul 19, 2018


This comment has been minimized.

Copy link
Contributor Author

commented Jul 19, 2018

Thanks for the reply.

This is more about documenting the behavior than providing individual build tags for each beta/RC release.

It could be possible to want to prevent a point release, e.g. !go1.10.1, from being used if it ever contains a really bad bug for a library, but probably this scenario has very low chances of showing up.

That's why I think it's useful to have the documentation cleared with regards to what a go1.x tag means and when it applies, which would also allow tools to correctly process these tag with relations to Go releases. The documentation on 1.10 has the same issue, so it's not a new problem in Go 1.11.

@ianlancetaylor ianlancetaylor added this to the Go1.12 milestone Jul 19, 2018


This comment has been minimized.

Copy link

commented Jul 19, 2018

I agree that this should be documented. We don't want fine-grained build tags for releases, so there are no go1.11rc1 or go1.10.1 build tags. Code that really needs that level of control, which I hope is very rare, can use runtime.Version.


This comment has been minimized.

Copy link

commented Sep 19, 2018

Change mentions this issue: go/build: clarify that there are no build tags for minor releases

@gopherbot gopherbot closed this in bf70ba0 Sep 27, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.