我假设您知道Haskell 包版本控制政策 (PVP)。这提供了一些指导,既隐含在它赋予版本的前三个组件(“ABC”)的含义中,也包括一些关于 Cabal 版本范围的明确建议。
粗略地说,具有相同“AB”的未来版本不会引入任何重大更改(包括引入可能会改变其他代码行为的孤立实例),但可能会添加新的绑定、类型等。前提是您只使用了合格的导入或显式导入列表:
import qualified Something as S
import Something (foo, bar)
您可以安全地编写以下形式的依赖项:
something >= 1.2.0 && < 1.6
例如,假设您已经1.2.0
通过测试1.5.6
,并且您确信它将继续与所有 future 1.5.x
s(非破坏性更改)一起运行,但可以想象会在 future 上中断1.6
。
如果您导入了一个不合格的包(如果您要重新导出其 API 的很大一部分,您可能会这样做),您将需要以下变体:
the-package >= 1.2.0 && < 1.5.4 -- tested up to 1.5.3 API
the-package >= 1.5.3 && < 1.5.4 -- actually, this API precisely
如果您定义一个孤立实例,还有一个警告(请参阅 PVP) 。
最后,在导入一些简单、稳定的包时,您只导入了最明显稳定的组件,您可能会做出以下假设:
the-package >= 1.2.0 && < 2
会很安全的。
查看 Cabal 文件中的一个大的、复杂的、编写良好的包可能会让您对实践中所做的事情有所了解。lens
例如,该包广泛使用以下形式的依赖项:
array >= 0.3.0.2 && < 0.6
但偶尔会有依赖,例如:
free >= 4 && < 6
(在很多情况下,这些更广泛的依赖关系都在同一个作者编写的包上,他显然可以确保不会破坏自己的包,因此可以稍微松懈一些。)