-
|
I am confused, I seem to not be able to select the v4.12.0 version in my golang project. I followed go-target.md to the letter, but still I am unable to pin the antlr4 module in my When adding the module, I seem to be able to only use one of the following release:
Has anyone been able to pin a specific version, and if yes what were the steps involved? |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 3 replies
-
|
You just have to use go get - it will get the latest version but because the go runtime is in a buried directory, go get -u will use the hash etc. for the tag in go.mod. But it does get the right code. I tried 2000 ways to make the tag be used in go.mod, but the only way to do this is to move the code to its own repo, which I am debating. But that would require changing the package name again. The master branch is always at the latest release of the runtime. You can also try the dev branch which is sitting on a number of improvements, if you don't need stability. I asked everyone I can think of about this, but the tags in the monorepo confuse it. |
Beta Was this translation helpful? Give feedback.
-
|
Hey @jimidle, yeah I feel your frustration and I understand it. I also tried so many different things and still I am a little unsure which tag is linked to which version of the antlr4 runtime :) I will keep monitoring the repository and future releases to see if something might change ... |
Beta Was this translation helpful? Give feedback.
-
|
Miles,
I am in charge of the repo for go, the runtime, and the tags. Sorry for the
confusion on that.
I meant that there is no way for me to do any better than this because go
will always create the mod tag like you see. The tag does represent 4.12.0
but go.mod will never tell you that.
There is no problem other than the tag not being shown in go.mod. It is a
pain, but that’s what it does. The architects don’t e pectoral/want us to
use a mono repo. I need to update the docs to explain this.
However, you have followed the docs and you are getting the latest released
go runtime. I never change the go source in master without an actual
release. I know that my only way around this is to move the go runtime to
its own repo. It will cause confusion forever this way.
Jim
…On Wed, Mar 22, 2023 at 18:17 Miles ***@***.***> wrote:
Hey @jimidle <https://github.com/jimidle>, yeah I feel your frustration
and I understand it. I also tried so many different things and still I am a
little unsure which tag is linked to which version of the antlr4 runtime :)
I will keep monitoring the repository and future releases to see if
something might change ...
—
Reply to this email directly, view it on GitHub
<#4201 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAJ7TMFOT6XNSNG3LPE5URDW5LGVFANCNFSM6AAAAAAWDNCRQE>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
Thank you for clarifying |
Beta Was this translation helpful? Give feedback.
-
|
No problem. |
Beta Was this translation helpful? Give feedback.
You just have to use go get - it will get the latest version but because the go runtime is in a buried directory, go get -u will use the hash etc. for the tag in go.mod. But it does get the right code. I tried 2000 ways to make the tag be used in go.mod, but the only way to do this is to move the code to its own repo, which I am debating. But that would require changing the package name again. The master branch is always at the latest release of the runtime. You can also try the dev branch which is sitting on a number of improvements, if you don't need stability.
I asked everyone I can think of about this, but the tags in the monorepo confuse it.