ivy中文参考文档(7)-最佳实践(下)

核心提示：5) 处理集成版本当工作在一个团队中或者多个模块时，你需要依赖中间的没有完成的模块版本，ivy中文参考文档(7)-最佳实践(下)，这些版本我们称之为集成版本，因为他们主要的目标就是和其他模块集成来构成或者测试一个运用或者框架，在你的构建系统中进行一些工作后，它可以引入一种机制来提升集成构建到更稳定的状态，如果你在模块开

5) 处理集成版本

当工作在一个团队中或者多个模块时，你需要依赖中间的没有完成的模块版本。这些版本我们称之为集成版本，因为他们主要的目标就是和其他模块集成来构成或者测试一个运用或者框架。

如果你在模块开发过程中欧那个遵循持续集成的规范，这些集成版本可以被持续集成服务器非常频繁的产生。

因此，如何处理这些可能数量繁多的集成版本呢？

主要有两种方法可以处理它们，ivy目前都支持：

1. 使用命名约定如一个特殊的后缀

这个主意非常简单，每次你发布你的模块的一个新的集成你使用相同的名字给这个版本(例如在maven世界中的 1.0-SNAPSHOT)。然后依赖管理器意识到这个版本是特殊的因为它始终在改动，因此它将不信任本地缓存，如果它已经有了这个版本。而是去检查仓库中这个版本的数据看它是否有改动。在ivy中对这个的支持是通过在依赖上使用changing 属性或者配置changing模式来使用所有的模块的方式来实现的。

2. 每次自动创建一个新版本

这种情况下使用build number或者时间戳来使用新的版本名称发布每个新的版本。然后你可以使用ivy提供的多个方式中的一个来"明确版本约束"。通常选择最新的一个(使用'latest.integration'作为版本约束)就足够了。

哪个方法最好？通常，这取决于你的上下文，如果这两个方法中的任何一个实际上不好用那么ivy不会去支持它:-)

但是通常我们推荐使用第二个方法，因为每次你发布一个新的版本时使用一个新的版本名称更符合版本身份规范，并且可以使你的所有的构建可重现，即使是集成版本。有趣的是，在你的构建系统中进行一些工作后，它可以引入一种机制来提升集成构建到更稳定的状态，类似里程碑或者发布。