-
Notifications
You must be signed in to change notification settings - Fork 17.8k
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
x/build: builders write a custom VERSION file with a simple "devel {hash}" format when testing Go #42221
Comments
Why this is a problem? I have a custom |
See #41116, and in particular #41116 (comment). I don't think there's anything wrong per se, but if tools want to start parsing information from |
Thanks. I agree that if tools want to parse Go version, it needs to be careful about arbitrary version strings. I don't think we want to disallow arbitrary version strings, though (it may not work for some tools, and that is probably fine). |
I personally don't have a horse in this race - I never create my own VERSION files, and I'm more than happy to have the tools I author simply error when a version string uses a custom format. The suggestion was by @heschik, so perhaps the need comes from gopls. cc @stamblerre |
If we want to have a discussion about whether it's a good idea to require the major version I think that belongs on #41116, not here. |
It was @dmitshur who requested a new issue be opened for the builders :) I personally prefer keeping discussion in the original issue. |
This issue should be about determining what needs to be done on the builder side to support changes for #41116, if anything, and doing it. CC @golang/release. There's more than one place in x/build that constructs a custom VERSION file, mostly related to debugging via The one that's relevant to testing commits is in |
Developers using toolstash also use custom version files in cases where you want to compare already-checked-in changes, see toolstash#hdr-Version_Skew. In case that matters. |
Thanks @cherrymui and @thanm for helpful context. After looking more into this, I left a comment on CL 264938 suggesting that it should not expect there to be any requirements met if there exists a We may still want to change the custom |
I don't think there's anything more to do here, so closing. |
See https://storage.googleapis.com/go-build-log/89055b21/android-amd64-emu_d4e8e53e.log. Instead of the usual format like
devel +94887410d4 Sun Oct 25 07:51:58 2020 +0000 linux/amd64
, they use a much simpler format via a VERSION file likedevel 89055b21aff36834cb8d338420e0c553cbe5ab7a
.This is a problem because the builds will end up with an entirely different version format. This issue tracks why this custom format was added, and hopefully making the builders result in the same version that
make.bash
produces.cc @dmitshur @heschik @bcmills @jayconrod
The text was updated successfully, but these errors were encountered: