在软件管理世界里存在着被称作“依赖地狱”的死亡之谷,系统规模越大,引入的程序包越多,你就越有可能在不久的将来发现自己深陷绝望之中。
在多依赖的系统中发布新版本程序包很快成为噩梦。如果依赖关系过紧密,可能面临版本控制被锁死的风险(必须对每一个依赖程序包改版才能完成某次升级)。而如果依赖关系过于松散,又无法避免版本混乱(\产生超过合理值的版本数/)。当你项目的进展由于版本控制被锁死和/或版本混乱变得不那么简便和可靠,也就意味着你正处于依赖地狱之中。
为了解决这个问题,我提议通过一些规则和约束来表述版本号如何命名及何时更新。要使此系统正常运作,你首先需要声明一个公共应用程序接口(以下简称API)。可以\以文档形式或代码形式实施/。需要注意的是,这个API必须是清晰和明确的。一旦公共API确定下来,你将通过版本号增量来描述版本修改。形如X.Y.Z(主版本号.副版本号.补丁号)这样的版本格式。通过增加补丁号来表示不影响API的错误修复,增加副版本号来表示兼容现有API的扩展/修改,而增加主版本号则表示不兼容现有API的修改。