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/dist: delete branchtag and its misleading use in findgoversion #42345
Comments
I think we can delete this as a next step, which shouldn't change behavior in meaningful ways, but make the current code easier to maintain and change in the future. Better to do it not during the freeze, so moving to next cycle. |
This issue is currently labeled as early-in-cycle for Go 1.18. |
I didn't get to this minor cleanup task in 1.18 cycle, will try next one. |
This issue is currently labeled as early-in-cycle for Go 1.19. |
Change https://go.dev/cl/393954 mentions this issue: |
Had a chance to look at this now. I see now this makes only a tiny dent, but sent a CL anyway. |
The
cmd/dist
script contains abranchtag
helper and the following code that uses it infindgoversion
:This comments suggests a certain behavior. As far as I can tell, this behavior happens almost never: release branches have always had a VERSION file checked in (going back as far as release-branch.go1 from 8 years ago), so execution inside
findgoversion
function won't reach that if statement. The only way I see fortag
and/orprecise
to be anything other than their initial values are if one checks out a release branch and intentionally deletes the committed VERSION file, then tries to build Go from source.(Perhaps this implementation worked better before the Go project transitioned from Mercurial to Git in commit f33fc0e, but I can't make sense of how it would have any effect since then.)
This issue is to investigate if my analysis is missing something. We may need to change this behavior in the future as part of work to make the development version string convey more accurate version information. This issue is would be relevant if we were to decide to change the release process to not keep the VERSION checked in on release branches (i.e., add it in one commit, remove in the next commit), but that seems unlikely.
If I'm missing something, please comment. Otherwise, I think we can delete the misleading nearly-dead code when the tree opens for Go 1.17 development.
CC @golang/release, @mvdan, @jayconrod, @dsymonds (in case you're still familiar this).
The text was updated successfully, but these errors were encountered: