-
Notifications
You must be signed in to change notification settings - Fork 251
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
shim for go1.11 is named go1.11.0 which does not match binary own opinion on its version #54
Comments
I understand, however keeping it correct according to semver is more important to me. I actually think we should've had 1.11.0{beta2,beta3,rc1,rc2}` to be consistent. |
Didn't mean to close issue w/o consensus. Since I'm refreshing the test suite in #62 I'll check if we can "hack" around matching |
This workarounds two sides' choices. First Golang does not release major versions, e.g `1.11.0` with the patch version of `0`. Second goenv only adds installable definitions with patch version as per semantic versioning by the book (arguably). The solution here is when provided with a install definition such as `1.11` to add a patch version of `0` automatically and the result will be a search for install definition `1.11.0`.
This workarounds two sides' choices. First Golang does not release major versions, e.g `1.11.0` with the patch version of `0`. Second goenv only adds installable definitions with patch version as per semantic versioning by the book (arguably). The solution here is when provided with a install definition such as `1.11` to add a patch version of `0` automatically and the result will be a search for install definition `1.11.0`.
This workarounds two sides' choices. First Golang does not release major versions, e.g `1.11.0` with the patch version of `0`. Second goenv only adds installable definitions with patch version as per semantic versioning by the book (arguably). The solution here is when provided with a install definition such as `1.11` to add a patch version of `0` automatically and the result will be a search for install definition `1.11.0`.
This workarounds two sides' choices. First Golang does not release major versions, e.g `1.11.0` with the patch version of `0`. Second goenv only adds installable definitions with patch version as per semantic versioning by the book (arguably). The solution here is when provided with a install definition such as `1.11` to add a patch version of `0` automatically and the result will be a search for install definition `1.11.0`.
This workarounds two sides' choices. First Golang does not release major versions, e.g `1.11.0` with the patch version of `0`. Second goenv only adds installable definitions with patch version as per semantic versioning by the book (arguably). The solution here is when provided with a install definition such as `1.11` to add a patch version of `0` automatically and the result will be a search for install definition `1.11.0`.
This workarounds two sides' choices. First Golang does not release major versions, e.g `1.11.0` with the patch version of `0`. Second goenv only adds installable definitions with patch version as per semantic versioning by the book (arguably). The solution here is when provided with a install definition such as `1.11` to add a patch version of `0` automatically and the result will be a search for install definition `1.11.0`.
[GH-54] Fix golang releases without patch version not being installed
Addressed in https://github.com/syndbg/goenv/releases/tag/2.0.0beta9 🎉 |
while it feels like bug in go, to omit .0 from version, I believe you should match version numbers exactly. Integration tests that put version into .go-version and try to parse that version back from
go version
output do fail due to this mismatch.The text was updated successfully, but these errors were encountered: