假设我有libfoo这取决于libbar.按照
Package Versioning Policy,我明确指出
libbar ==0.1.*
在Build-depends中：在我的cabal文件中.
然后,libbar的开发者发布了一个新版本,0.2.我测试它,没有影响libfoo的更改.所以我改变我的构建依赖
libbar ==0.2.*
或者也许
libbar >= 0.1 && < 0.3
虽然我可以想到不这样做的原因.这是我对libfoo的唯一改变.
libfoo导出接受在libbar中定义的类型和在libbar中定义的返回类型的函数.但是,对libbar的更改不会影响任何这些功能.
libfoo的第一个版本是0.1.0.0. libfoo的第二个版本应该有哪些版本号？
这取决于您从libbar重新导出的内容.
你是否重新导出libbar？
不太可能,但….
鉴于libbar已经将其主要数字从0.1改为0.2,有可能会在更改中破译代码,如果您重新出口批发,您的主要编号也必须改变：0.2.0.0
libbar 0.2是否声明新的实例？
这是值得注意的一个.
没有办法阻止跨模块边界泄露的实例,新的实例可能会破坏现有的代码.这就是版本策略说的原因
Note that modifying imports or depending on a newer version of another package may cause extra instances to be exported and thus force a major version change.
如果libbar 2.0中有新的实例,则必须有一个新的主版本：0.2.0.0.
除此以外
在这种情况下,你的代码不会改变.软件包版本策略的第2点不适用：
- Otherwise,if only new bindings,types,classes or modules (but see below) were added to the interface,then A.B may remain the same but the new C must be greater than the old C.
一个基本原则是：
A.B.C uniquely identifies the API.
您没有添加任何内容或更改导出的任何内容,因此您不需要从0.1.0更改主要次要号码,但应更改最后一部分：0.1.0.1是正确的.
