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

Jump to bottom

cmd/go: build tags for beta and RC builds clarification #26458

Closed
dlsniper opened this issue Jul 19, 2018 · 4 comments
Closed

cmd/go: build tags for beta and RC builds clarification #26458

dlsniper opened this issue Jul 19, 2018 · 4 comments
Labels
Documentation FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done.
Milestone
Go1.12

Comments

@dlsniper
Copy link
Contributor

Hi,

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.
@mvdan
Copy link
Member

mvdan 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 https://tip.golang.org/pkg/go/build/#hdr-Build_Constraints:

  • "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 tip.godoc.org, I'm not sure how useful it would be for everyday users downloading 1.11 betas.

@dlsniper
Copy link
Contributor Author

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 the NeedsFix The path to resolution is known, but the work has not been done. label Jul 19, 2018
@ianlancetaylor ianlancetaylor added this to the Go1.12 milestone Jul 19, 2018
@ianlancetaylor
Copy link
Contributor

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.

@gopherbot
Copy link

Change https://golang.org/cl/136215 mentions this issue: go/build: clarify that there are no build tags for minor releases

@golang golang locked and limited conversation to collaborators Sep 27, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
Documentation FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done.
Projects
None yet
Milestone
Go1.12
Development

No branches or pull requests
4 participants
@dlsniper @ianlancetaylor @mvdan @gopherbot