Haskell软件包版本控制策略 – 依赖关系的更改

发布时间：2020-12-13 20:24:53 所属栏目：百科来源：网络整理

导读：假设我有libfoo这取决于libbar.按照 Package Versioning Policy,我明确指出 libbar ==0.1.* 在Build-depends中：在我的cabal文件中. 然后,libbar的开发者发布了一个新版本,0.2.我测试它,没有影响libfoo的更改.所以我改变我的构建依赖 libbar ==0.2.* 或者也

假设我有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是正确的.

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!