The cmd/dist script contains a branchtag helper and the following code that uses it in findgoversion:
// If we're on a release branch, use the closest matching tag
// that is on the release branch (and not on the master branch).
if strings.HasPrefix(branch, "release-branch.") {
tag, precise = branchtag(branch)
}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 for tag and/or precise 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
cmd/distscript contains abranchtaghelper 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
findgoversionfunction won't reach that if statement. The only way I see fortagand/orpreciseto 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).