嗨，我无法建立。 得到错误：

/workpath/go/pkg/mod/github.com/garyburd/ [email protected]+incompatible/redis/pool.go ：28：2：不允许使用内部软件包github.com/gomodule/redigo/internal

我的go.mod中有2个redigo。

要求 （
...
github.com/garyburd/redigo v2.0.0 +不兼容
github.com/gomodule/redigo v2.0.0 +不兼容//间接
...
）

Go版本：v1.11

@huaguoping使用github.com/garyburd/redigo v1.6.0代替v2.0.0。 更好的是，使用此程序包。

@huaguoping使用github.com/garyburd/redigo v1.6.0代替v2.0.0。

谢谢。 👍

按照go 1.11中go模块引入的“语义导入版本控制”，将模块的主要版本增加到1以上需要一个新的导入路径。 看：

在语义版本控制中，更改主版本号表示缺少与早期版本的向后兼容性。 为了保持导入兼容性，go命令要求主版本为v2或更高版本的模块使用主版本为最终元素的模块路径。 例如，example.com / m的v2.0.0版本必须改为使用模块路径example.com/m/v2，并且该模块中的软件包将使用该路径作为其导入路径前缀，例如example.com/m/v2 / sub / pkg。 以这种方式在模块路径和导入路径中包含主要版本号称为“语义导入版本控制”。

模块兼容性和语义版本控制

执行此操作的首选方法通常是创建v2分支，将/v2附加到模块名称（go.mod文件的第一行），更新导入路径以包含/v2 ，并标记新的v2.x.x版本。 那应该是所有需要的。 离开v2的导入将获得最高的v1.xx，而包括v2的导入将获得最高的v2.xx。

请参阅从存储库到模块。

挑战在于该存储库已经是v2，因为它已被标记
因此，在存在模块之前（它们仍然不是“最终的”）。

您可以发布v2.0.1并更新导入路径，但存在以下风险：
打破现有用户和模块用户的一致。
2018年11月30日星期五，下午3:07 John Refior [email protected]
写道：

按照go 1.11中go模块引入的“语义导入版本控制”，
将模块的主要版本增加到1以上需要重新导入
小路。 看：

在语义版本控制中，更改主版本号表示缺少
与早期版本的向后兼容性。 保留进口
兼容性，go命令要求主版本为v2的模块
或更高版本，请使用具有该主要版本的模块路径作为最终元素。
例如，example.com / m的v2.0.0版本必须改为使用模块路径
example.com/m/v2，并且该模块中的软件包将使用该路径作为
它们的导入路径前缀，例如example.com/m/v2/sub/pkg。 包括
模块路径和导入路径中的主要版本号是
称为“语义导入版本控制”。

模块兼容性和语义版本控制
https://golang.org/cmd/go/#hdr-Module_compatibility_and_semantic_versioning

首选的方法通常是创建一个v2分支，追加/ v2
到模块名称（go.mod文件的第一行），将导入路径更新为
包括/ v2，并标记一个新的v2.xx版本。 那应该就是全部了
必需的。 离开v2的导入将获得最高的v1.xx
可用，而包含v2的导入将获得最高的v2.xx
可用的。

请参阅从存储库到模块https://research.swtch.com/vgo-module 。

-
您收到此邮件是因为您发表了评论。
直接回复此电子邮件，在GitHub上查看
https://github.com/gomodule/redigo/issues/366#issuecomment-443324080 ，
或使线程静音
https://github.com/notifications/unsubscribe-auth/AABIcDYwhnhJPPlm9NVo3g1__LnXc1_iks5u0Y_kgaJpZM4W31s-
。

要求：现有用户无需更改代码或工具即可继续使用该程序包的当前版本。 这包括使用Go 1.8和更低版本的用户，使用go get获取代码的用户等。

Glide允许Go 1.5+用户锁定特定版本的软件包。 但是，如果我正确理解了这一要求，那么您还将尝试支持不使用依赖项管理工具的Go 1.8和更早版本的用户，并且总是会使用go get获得“最新”消息-是正确的吗？

当前的“最新”版本是否适用于它们，或者您是否正在尝试通过下一发行版将它们移回某个先前的版本？

虽然我个人更喜欢使用带有go模块的v2分支的v2分支机制，但在某些情况下，仅当您遵循语义版本控制并且假定使用Go的较早版本的用户可以/将/应该获取适用于该版本的较旧的发行版标签时，该方法才有效他们的版本。 在这里，听起来好像您想向后兼容，即使该假设不成立（Go创造者一开始想要的）。

再一次，您将内部导入路径隔离开来，这些导入路径会受到/v2导入路径更改的影响。 Garyburd在＃363（ link ）中提出了一个解决方案。 在这一点上，它对我来说似乎很有前途，但是我认为我对这个存储库的早期版本以及对Go早期版本的用户的支持不够了解，无法确定是否可以满足您的所有需求。 社区是否已确定是否这样做？

关于该提案中对Go模块的支持，我认为只要您的go.mod github.com/gomodule/redigo/v2在您的下一个v2.xx版本中将名称定义为go.mod标签的v1.xx版本，该版本定义了不带/v2 ，并具有适当的导入路径以支持“ v1”。

另外，我认为采用go模块迁移到v2的目录方法可能确实满足您的目标（如果我正确理解了这种情况）。 正如拉斯·考克斯（Russ Cox）所描述的那样：

作为替代方案，vgo还支持“主要子目录”约定，在该约定中，v1以上的主要版本在子目录中开发。 在这种情况下，创建v2.0.0的方法不是将整个树分叉到一个单独的分支中，而是将其复制到一个子目录中。 同样，必须将go.mod更新为“ my / thing / v2”。 之后，指向提交的v1.xx标记可寻址根目录中的文件（不包括v2 /），而指向提交的v2.xx标记仅可寻址v2 /子目录中的文件。 go.mod文件使vgo可以区分这两种情况。 让v1.xx和v2.xx标记指向同一提交也将是有意义的：它们将处理提交的不同子树。

我们希望开发人员会对选择一种约定或另一种约定有强烈的信心。 vgo不支持双方，而是支持两者。 请注意，对于高于v2的主要版本，主要子目录方法可能会为go get用户提供更为平稳的过渡。 另一方面，Dep或供应商工具的用户应该能够使用这两种约定使用存储库。 当然，我们将确保dep可以。

请参阅从存储库到模块

在这种情况下，您可以选择（通过将代码保留在v2目录之外）将哪个版本的代码显示为“ v1”：在没有任何依赖项管理工具的情况下，用户将通过简单的“ go get”获得什么; 以及使用依赖管理工具的现代版Go用户如果不使用v2导入路径，也会得到什么。

然后，在v2目录中，您可以通过指定v2导入路径，为支持移动到“ v2”的用户放置支持Go的现代版本的代码。

当前最新作品为1.5及更高版本。

在2018年12月2日，星期日，上午6:37 John Refior [email protected]写道：

现有用户无需更改代码或工具即可继续使用
软件包的当前版本。 这包括使用Go 1.8及更低版本的用户，
使用go get获取代码的用户，等等。

Glide允许Go 1.5+用户锁定特定版本的软件包。 但是如果我
正确理解此要求，您也在尝试支持用户
Go 1.8及更早版本中未使用依赖项管理工具的团队，以及
用go get总是总是“最新”的-正确吗？

当前的“最新”版本对他们有用吗，还是您要移动它们？
通过下一个发行版返回一些以前的版本？

-
您收到此消息是因为您创建了线程。
直接回复此电子邮件，在GitHub上查看
https://github.com/gomodule/redigo/issues/366#issuecomment-443512335 ，
或使线程静音
https://github.com/notifications/unsubscribe-auth/AACCg3iWVKvJ0eyPrbsRhxCSiHvqBixFks5u0-WSgaJpZM4W31s-
。

@jrefior ：我更新了此问题，以阐明我们今天所处的位置以及我的要求。 让我知道那是否不能回答您的问题。

全部：我删除了有关不相关问题的评论。

它对孤立的v2.0.0起作用并继续在v1.xx上继续发布可以无缝添加go.mod文件的版本吗？

您已经提到了孤立v2.0.0。 如果保留v2.0.0标记并继续在v1.xx上进行开发，则某人或某些依赖项管理工具将在尝试获取最新版本时拉动v2.0.0。 因此，您必须删除v2.0.0标记，并在该位置创建一个新的1.x.0标记。

在这里，我试图做到这一点。 我分叉了存储库，删除了v2.0.0标记（ git push --delete origin v2.0.0 ），添加了go.mod文件，并标记了新的v1.7.0版本： https :

如果您愿意删除v2.0.0标记，那么与其他解决方案相比，这可能会实现更多的目标。 用户可能必须更改其依赖项管理配置，但不必更改其代码。 否则，在某些时候，新版Go的用户将不得不更改其导入路径以包含/v2 。

你怎么看？

已经拉过v2.0.0并将其包含在其用户中的用户会发生什么情况
依赖清单？
在2019年1月19日星期六11:23 AM John Refior [email protected]
写道：

您已经提到了孤立v2.0.0。 如果您将v2.0.0标记保留在原位
并继续在v1.xx，某人或某些依赖项管理上进行开发
尝试获取最新版本时，该工具将拉出v2.0.0。 所以你必须删除
v2.0.0标记，并在该位置创建一个新的1.x.0标记。

在这里，我试图做到这一点。 我分叉了存储库，删除了v2.0.0标记（git
push --delete origin v2.0.0），添加了go.mod文件，并标记了新
v1.7.0版本： https :
它下来或使用具有不同版本的各种依赖管理工具
如果您愿意，可以指定测试规格。

如果您愿意删除v2.0.0标记，那么我认为这可以完成
您的目标比任何其他解决方案都多。 否则在某些时候用户
的新版本Go必须更改其导入路径以包括
/ v2。

但是，如果您愿意要求/ v2导入路径来获取最新的
代码-不指定v2只会为您提供最高的v1.xx版本
-我认为具有构建约束的分支模型也将起作用。

你怎么看？

-
您收到此邮件是因为您发表了评论。
直接回复此电子邮件，在GitHub上查看
https://github.com/gomodule/redigo/issues/366#issuecomment-455807916 ，
或使线程静音
https://github.com/notifications/unsubscribe-auth/AABIcFYcGZ_mM6wmm_3R06P2zCx7HFZZks5vE3CvgaJpZM4W31s-
。

没错，这就是问题所在，因为那是可能存在的弊端。 以及使用不同的依赖项管理工具进行测试的原因。

因此，例如，如果我在进行中1.11.4，然后通过删除go.mod文件并进行提交和标记来“还原” v2.0.0，然后通过go get从其他项目导入jrefior / redigo，我将看到这个：

$ go get github.com/jrefior/redigo/redis
go: finding github.com/jrefior/redigo/redis latest
go: finding github.com/jrefior/redigo v2.0.0+incompatible
go: downloading github.com/jrefior/redigo v2.0.0+incompatible
$ cat go.mod
module opensource/test01

require github.com/jrefior/redigo v2.0.0+incompatible // indirect
$ cat go.sum
github.com/jrefior/redigo v2.0.0+incompatible h1:DnvDEZJV+Z/ulWZhD5r/L7/bziq203lzvd2AUi5C9S8=
github.com/jrefior/redigo v2.0.0+incompatible/go.mod h1:msepy20fPwm2qIMjp3xi0iLG66J+DoYk66NT0Jt7Oso=

现在，当我删除标签v2.0.0并再次提交go.mod文件和标签v1.8.0时，现在我尝试再次构建测试项目：

$ go build
$

构建就可以了。 但这是因为它正在从我的模块缓存（ $GOPATH/pkg/mod ）中加载jrefior/redigo 。 如果我通过更改gopath设置了新的模块缓存，则尝试建立错误：

$ go build
go: finding github.com/jrefior/redigo v2.0.0+incompatible
go: github.com/jrefior/[email protected]+incompatible: unknown revision v2.0.0
go: error loading module requirements

并且没有构建二进制文件。 因此，用户必须采取一些措施来解决问题。 在这种情况下，即使您指定了所需的新版本， go get或go get -u也无法解决。 您唯一的解决方案是手动编辑go.mod文件（更改版本或删除需求，然后让go工具在构建时再次发现它）。

在我看来，这不是很好的用户体验。 可以使用glide and dep和其他依赖项管理工具重复此测试。

不幸的是，我认为仅在不删除v2.0.0的情况下仅继续在v1.xx上进行开发/维护可能会更糟，因为许多尝试获取最新版本的用户会无意间跳入v2.0.0，无声地获取最新代码。

为了避免这两种情况，您可以将模块名称设置为github.com/gomodule/redigo/v2并要求go-module-aware用户将v2到其导入路径中以获得v2.xx代码（如果您是愿意这样做。

这个怎么样：

• 添加具有内容的go.mod文件：

  模块github.com/gomodule/redigo/v2

• 更改测试以导入github.com/gomodule/redigo/v2

• 标记新的v2.xx版本

• 创建一个v1分支并将该分支上的go.mod更改为：

  模块github.com/gomodule/redigo

• 标签v1.xx在v1分支上发布。

• 编写脚本至：
  
  
  
  • 标记v2.xx版本
  
  
  • 合并从master到v1分支的更改
  
  
  • 标签v1.xx在v1分支上发布
  
  

测试将在v1分支中失败。 其他一切都应该起作用。

因为它似乎你打算让大多数消费者使用v1.7.0标记，不老的v2.0.0标签，如果你发布什么v1.7.1与module github.com/gomodule/redigo并在分开，例如说v2分支，用module github.com/gomodule/redigo/v2释放v2.0.1 module github.com/gomodule/redigo/v2 。

我可以想象不支持v2.0.0代码库，因此该建议可以使模块客户忽略v2行，除非他们特别要求。 唯一的缺点是它将您锁定为v2 api兼容性，但是我认为v2.0.0标签已经做到了。

如果这是一个可行的解决方案，我认为＃413可以为v1.7.1零钱提供服务，您是否希望我为v2.0.1另一个零钱？

@arnottcr因为创建v2标签是错误的，所以我想忽略它。 问题在于人们会认为v2优于v1。 v2的状态可以在自述文件中进行说明，但这只会帮助那些实际读取文件的人。

也许最好的选择是将v1和v2与v1并行开发，作为开发的主线。可以编写脚本来合并从v1到v2的更改，并根据需要创建v2标签。 这与我在这里描述的相反。

这样做是有道理的，我认为在这种情况下，您可能需要考虑主要的子目录选项，并将类型别名与goforward之类的工具结合使用，以使您自己更轻松。 您可能看到的唯一破损是针对使用dep ， glide等工具的人，这些人当前正在从导入github.com/gomodule/redigo消费v2.x.x行。

413模拟了该提议，但是可以更改为使用v3而不是v2 ，或者，如果最后一次提交分解为另一个分支，则可以采用主要分支模型。

同意也许我们可以得到一个v3。 现在，每次执行go get -u我的1.7都会升至2.0，并且我必须手动编辑文件以降低版本，这是不理想的。

有什么理由不删除v2.0.0标签吗？

这不是100％理想，但是v3可能会减少所有弊端，想法吗？

标签必须不按照semver规范中删除，也不能从模块代理删除，所以删除将是一个空操作。

这不是100％理想，但是v3可能会减少所有弊端，想法吗？

听起来不错。 比目前的情况要好。

（仅供参考）要使用此模块的最新版本，可以使用伪版本控制：

go get github.com/gomodule/[email protected]

然后只需将go.mod的原始gomodule / redigo替换github.com/gomodule/redigo v0.0.0-20191011215927-4f569a470858

注意到rsc在另一个将Go Modules支持添加到开源软件包中的帖子中的帖子，并认为一些考虑此问题中的选项的人可能会发现这很有用：
Russ Cox回复Badger v2帖子

您可以使用具有正确v2模块名称的go.mod创建一个寿命很长的v2分支，然后在每次剪切新的v1版本时将所有已发布的更改从master合并到该分支中...然后使用v2分支进行v2版本...使其与v1版本保持同步。 这将允许未指定v2模块名称的go get安装按预期工作，并且v2版本也将保持同步。