版本管理。

冷不防 2024-02-19 13:24 19阅读 0赞

为了方便团队的何做，在项目开发的过程中，大家都应该使用快照版本，Maven能够很智能的处理这种特殊的版本，解析项目各个模块最新的“快照”。快照版本机制促进团队内部的交流。但是当项目需要对外发布时，我们显然需要提供非常稳定的版本，使用该版本应当永远只能够定位到唯一的构件，而不是像快照版本那样，定位的构件随时可能发生变化。对应的，我们称这类稳定的版本为发布版。项目发布了一个版本之后，就进入下一个开发阶段，项目也就自然转换到新的快照版本中。

版本管理关心的问题之一就是这种快照版和发布版之间的转换。项目经过了一段时间的1.0-SNAPSHOT的开发之后，在某个时刻发布了1.0正式版，然后项目又进入了1.1-SNAPSHOT的开发，这个版本可能添加了一些有趣的特性，然后在某个时刻发布1.1正式版。项目接着进入1.2-SNAPSHOT的开发。由于快照对应了项目的开发过程，因此往往对应了很长的时间，而正式版本对应了项目的发布，因此仅仅代表某个时刻项目的状态。

理想的发布版本应当对应了项目某个时刻比较稳定的状态，这包括源代码以及构建的状态，因此这个时候项目的构建应当满足以下的条件：

*  **所有自动化测试应当全部通过。**毫无疑问，失败的测试代表了需要修复的问题，因此发布版本之前应该确保所有测试都能得以正确执行。
 *  **项目没有配置任何快照版本的依赖。**快照版本的依赖意味着不同时间的构建可能会引入不同内容的依赖，这显然不能保证多次构建能够生成同样的结果。
 *  **项目没有配置任何快照版本的插件。**快照版本的插件配置可能会在不同时间引入不同内容的Maven插件，从而影响Maven的行为，破坏构建的稳定性。
 *  **项目所包含的代码已经全部提交到版本控制系统中。**项目已经发布了，可源代码却不再版本控制系统中，甚至丢失了。这意味着项目丢失了某个时刻的状态，因此这种情况必须避免，版本发布的时候必须确保所有的源代码都已经提交了。

只有上述条件都满足之后，才可以将快照版本更新为发布版本。例如将1.0-SNAPSHOT更新为1.0，然后生成版本为1.0的项目构件。

不过这里还缺少一步关键的版本控制操作。如果你了解任何一种版本控制工具，如Subversion，通常这些变化都被维护在主干中，包含各种源码版本r1、r2、...、r284、...。要找到某个时刻的项目状态会比较麻烦，而使用标签就可以明确的将某个源码版本（也就是项目状态）从主干中标记出来，放到单独的位置，这样在之后的任何时刻，我们都能快速的得到发布版本的源代码，从而能够比较各个版本的差异，甚至重新构建一个同样版本的构件。

因此，将项目的快照版本更新至发布版本之后，应当再执行一次Maven构件，以确保项目状态是健康的。然后将这一变更提交到版本控制系统的主干中。接着再为当前主干的状态打上标签。