You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I found that packages, say github.com/dyatlov/go-opengraph/opengraph, are placed in submodule github.com/dyatlov/go-opengraph/opengraph instead of root module.
However, it seems that submodule github.com/dyatlov/go-opengraph/opengraph is not tagged. According to go docs, submodule should be tagged like relative-path-to-root/vX.X.X.
At now, when trying to import package github.com/dyatlov/go-opengraph/opengraph, downstream would depends on pseudo-version of module github.com/dyatlov/go-opengraph/opengraph.
I think it is not very readable and difficult to upgrade. This is not conductive to version control either.
So, I propose whether it is possible to tag submodule properly. For example, opengraph/v0.0.1, opengraph/v1.0.1etc, so that other project can use tag to import this module in go.mod.
Another suggestion relates to issue #7. According to Go Modules wiki, specifying a require entry on newer version, at or after submodule being carved out, of root module github.com/dyatlov/go-opengraph in submodule's go.mod may avoid downstream's potential ambiguous import error.
The text was updated successfully, but these errors were encountered:
I found that packages, say
github.com/dyatlov/go-opengraph/opengraph
, are placed in submodulegithub.com/dyatlov/go-opengraph/opengraph
instead of root module.However, it seems that submodule
github.com/dyatlov/go-opengraph/opengraph
is not tagged. According to go docs, submodule should be tagged likerelative-path-to-root/vX.X.X
.At now, when trying to import package
github.com/dyatlov/go-opengraph/opengraph
, downstream would depends on pseudo-version of modulegithub.com/dyatlov/go-opengraph/opengraph
.I think it is not very readable and difficult to upgrade. This is not conductive to version control either.
So, I propose whether it is possible to tag submodule properly. For example,
opengraph/v0.0.1
,opengraph/v1.0.1
etc, so that other project can use tag to import this module in go.mod.Another suggestion relates to issue #7. According to Go Modules wiki, specifying a require entry on newer version, at or after submodule being carved out, of root module
github.com/dyatlov/go-opengraph
in submodule's go.mod may avoid downstream's potential ambiguous import error.The text was updated successfully, but these errors were encountered: