go.mod中不兼容的内容会造成伤害吗？

问题描述：

I'm using goczmq in my project, something like next:

main.go:

package main

import (
    _ "github.com/zeromq/goczmq"
)

func main() {
}

And more, I'm using golang 1.12 with gomod to manage my project.

See next, I use go mod init xxx, and when build, it downloads goczmq automatically for me and add dependency to go.mod, but has incompatible in it. (But for other library I may get something like github.com/kolo/xmlrpc v0.0.0-20190717152603-07c4ee3fd181)

go.mod:

module pigeon

go 1.12

require (
    github.com/zeromq/goczmq v4.1.0+incompatible
)

From some discussion (for other library), e.g. this, it seems the library owner should do something to support golang 1.12? But in my case, all things works fine just a incompatible there make me a little worried (I mean all seems ok now, but some day when I use an api which I never used before, there will be hidden bomb there...?)

So my question:

Should I worry about this, or this is just as expected?

我正在使用 goczmq 在我的项目中，类似下一个： p>

main.go： strong> p>

  包main 
 
import（
 _“ github.com/zeromq/goczmq"
)

func main（）{
} 
  code>  pre> 
 
  还有更多，我将golang 1.12和gomod一起使用来管理我的项目。 p> 
 
 
请参阅下一步，我使用 go mod init xxx  code>，以及在构建时 ，它会自动为我下载goczmq并向 go.mod  code>添加依赖项，但其中包含 incompatible  code>。  （但对于其他库，我可能会得到类似 github.com/kolo/xmlrpc v0.0.0-20190717152603-07c4ee3fd181  code>的东西） p> 
 
 
  go.mod：   strong>  p> 
 
 
 模块鸽
 
go 1.12 
 
require（
 github.com/zeromq/goczmq v4.1.0 + incompatible 
）
   pre> 
 
 通过一些讨论（针对其他库），例如 此，看来图书馆所有者应该做些事情来支持golang 1.12？ 但就我而言，所有事情都正常运行，只是一个 incompatible  code>，这让我有些担心（我的意思是，现在一切似乎都还可以，但是有一天，当我使用从未使用过的api时， 隐藏的炸弹...？） p> 
 
 
 所以我的问题 strong>  p> 
 
 
我应该为此担心还是这个 符合预期？ p> 
  div>

答

+incompatible means the dependency has a semver major version of 2 or higher and is not a Go module yet (it doesn't have go.mod in its source code).

答

Accepted answer is correct, but really not friendly for me who just get in touch with go module. I made some investigation base on the answer & make a conclusion base on this as next, in case anyone needed:

Standard commands like go build or go test will automatically add new dependencies as needed to satisfy imports (updating go.mod and downloading the new dependencies). But there are several different situations which will result in the different version selections:

If a repository has not opted in to modules but has been tagged with valid semver tags, meanwhile, it's v0/v1 module, see this:

not opted in to modules: means no go.mod in source tree

valid semver tags: means the repo use git tag to tagged as something like vX.Y.Z

v0/v1 module: means the value of major version(that is X) is 0 or 1, e.g. v0.1.0, v1.2.3

Then, it will use a pseudo-version, something like github.com/kolo/xmlrpc v0.0.0-20190717152603-07c4ee3fd181
If a repository has not opted in to modules but has been tagged with valid semver tags, meanwhile, it's a v2+ module, see this:

v2+ module: means the value of major version(that is X) is >=2,e g. v4.1.0

Then, it will show as incompatible, something like github.com/zeromq/goczmq v4.1.0+incompatible
If a repository has already opted in to modules, but not have been tagged with valid semver tags:

Then, it will behave as 1, use pseudo-version.
If a repository has already opted in to modules, and has been tagged with valid semver tags, meanwhile, it's a v0/v1 module:

Then, it will behave normally like github.com/stretchr/testify v1.3.0
If a repository has already opted in to modules, and has been tagged with valid semver tags, meanwhile, it's a v2+ module:

Then, when import in sourcecode, we need add /vN at the end, e.g., import "github.com/my/mod/v4", and in go.mod it will behave like github.com/my/mod/v4 v4.1.0

go.mod中不兼容的内容会造成伤害吗？

相关推荐