Maven版本管理30.pdfVIP

MAVEN 版本管理 作者:yinhongzhan@ 概要 为了方便团队合作,在项目开发的过程中,大家都应该使用快照版本,Maven 能很智能的 处理这种特殊的版本,解析项目各个模块的最新的快照.快照版本能促进团队内部交流,但 是项目需要对外发布时,我们显然要提供非常稳定的版本,使用该版本应当永远只能够定位到 唯一的构件,而不是像快照版本一样,定位构件随时可能发生变化. 当我们发布一个项目正式 版本后,就可以进入下一个开发阶段,项目也就自然的转化到新的快照版本中. 项目版本管理关心的问题之一就是上面提到的快照版和正式发布版之间的切换. 首先来说明下理想的发布状态:  所有自动化测试全部通过  项目内部没有任何的快照版本依赖  项目中没有配置任何快照版本的插件  项目的代码应该已经全部提交到版本控制系统中 理论上来说应该满足以上几点才能发布版本. 版本号定义约定 在 使 用 一 些 开 源 框 架 时 , 大 家 都 会 看 到 很 多 版 本 号 , 如 springfrxxxx3.1.1,sprngfrxxxx3.0.1,junit3.8 等 Maven 中的版本号约定是这样的: 主版本.次版本.增量版本-里程碑版本 可以看到在除了里程碑版本外其他版本之间使用点号分割的.下面来说明下每种的意义: 主版本: 表示项目的重大架构变更. 例如 Maven2 和Maven1 相去甚远;Struts1 和2 则更是采 用了不用的架构.JUnit4 比JUnit3 增加了注解标记 次版本: 表示较大范围的功能增加和变化,及BUG 修复.但从总体架构上来说没有什么变化. 增量版本: 一般表示重大的 BUG 的修复.例如项目发布了 1.0.0 版本后发现了一个影响功能的 重大BUG,则应快速修复并发布为1.0.1 里程碑版本: 这些版本往往表示还不是非常稳定,需要很多测试.如1.0.0-beta1,1.0.0-alpha1 等 我们的使用版本号也按照此约定来进行. 主干、标签和分支 分支1.1.1-Snapshot 1.1.1 合并 1.0.0 1.2.0 1.3.0 1.0.0-Snapshot 1.1.0-Snapshot 1.2.0-Snapshot 1.3.0-Snapshot 画了一个图方便大家理解,我举个例子来说明这几个概念,假如某个项目要开始开发,这 时候的版本即是 1.0.0-Snapshot 状态,经过大家一个月的努力,功能全部完成了,这时候可以发 布一个版本 1.0.0,然后项目就进入了 1.1.0-Snapshot 状态,添加了一些新特性和修复了很多 BUG 后团队很开心的宣布1.2.0 诞生了,但是过了几天后,测试部反映上来了一个重大的BUG, 需要尽快修复,而这时候开发们也早已经进入了 1.2.0-Snapshot 状态了,这时候我们既不能停 止1.2.0-Snapshot 的开发,又由于主干的变数太多,这时候我们就可以创建一个1.1.1-Snapshot 分支,在这里进行BUG 的修复,然后为用户发布一个1.1.1 的增量版本, 同时打上标签, 当然不能 忘了把BUG 修复设计的变更合并到1.2.0-Snapshot 中,主干的1.2.0-Snapshot 在开发一段时间 后发布了1.2.0 版本,然后进入了1.3.0-Snapshot 的开发过程中. 通过上面的这个例子大家也应该明白了这个 3 个概念的意义,这也是一个不成文的行业 规定,对大家学习开源框架也比较好 自动化发布 前面说的内容主要是为了方便大家理解后面所述.所以现在才是重头戏. 在上面介绍了一下标准的发布流程,作为一个程序