-
-
Notifications
You must be signed in to change notification settings - Fork 178
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
Submodules are not tagged correctly. #517
Comments
Could you please take a look at this issue @dosco ? Many thanks :) |
i can't seem to get go to use go.work also where did you read that relative paths are allows they don't seem to be. I switched to using |
i tried some ideas to fix the issue even upgraded a ton of packages and go versions but not luck
|
wonder if we need to restructure the repo to make this work? |
@dosco Thanks so much for your response! Sorry for the late reply.
The problem lies in you haven't released a tag version for
There's no need to alter the project structure; you just need to release a tag for |
You can refer to this link |
thanks spent hours did not find this doc. i'll try this so will release a /vVersion tag per package. i ended up removing go.work and switched to using replace will go back and try using go.work |
Thanks for your effort! |
What version of GraphJin are you using?
graphjin version
v3.0.1
Have you tried reproducing the issue with the latest release?
Yes.
Steps to reproduce the issue.
Run
go get github.com/dosco/graphjin/core/v3 v3.0.31
Expected behaviour and actual result.
It seems that current
graphjin
has mutliple submodules with their owngo.mod
, for example,core
andcmd
.However, it seems that the submodules are not properly tagged. According to Go Modules standard , submodule should be tagged like relative-path-to-root/vX.X.X.
At now, when trying to import package
github.com/dosco/graphjin/core
, downstream project would have to depend on pseudo-version of it and cannot get a valid tag version.To address this, i think it's better to tag submodules properly according to Go standard, for example, releasing a tag `core/v3.0.31``, so that downstream project can use tag version to import the submodule in go.mod.
The text was updated successfully, but these errors were encountered: