6.5节谈到，为了方便团队的合作，在项目开发的过程中，大家都应该使用快照版本，Maven能够很智能地处理这种特殊的版本，解析项目各个模块最新的“快照”。快照版本机制促进团队内部的交流，但是当项目需要对外发布时，我们显然需要提供非常稳定的版本，使用该版本应当永远只能够定位到唯一的构件，而不是像快照版本那样，定位的构件随时可能发生变化。对应地，我们称这类稳定的版本为发布版。项目发布了一个版本之后，就进入下一个开发阶段，项目也就自然转换到新的快照版本中。
版本管理关心的问题之一就是这种快照版和发布版之间的转换。项目经过了一段时间的1.0-SNAPSHOT的开发之后，在某个时刻发布了1.0正式版，然后项目又进入了1.1-SNAPSHOT的开发，这个版本可能添加了一些有趣的特性，然后在某个时刻发布1.1正式版。项目接着进入1.2-SNAPSHOT的开发。由于快照对应了项目的开发过程，因此往往对应了很长的时间，而正式版本对应了项目的发布，因此仅仅代表某个时刻项目的状态，如图13-1所示。
图13-1 快照版和发布版之间的转换
理想的发布版本应当对应了项目某个时刻比较稳定的状态，这包括源代码的状态以及构建的状态，因此这个时候项目的构建应当满足以下的条件：
·所有自动化测试应当全部通过。毫无疑问，失败的测试代表了需要修复的问题，因此发布版本之前应该确保所有测试都能得以正确执行。
·项目没有配置任何快照版本的依赖。快照版本的依赖意味着不同时间的构建可能会引入不同内容的依赖，这显然不能保证多次构建能够生成同样的结果。
·项目没有配置任何快照版本的插件。快照版本的插件配置可能会在不同时间引入不容内容的Maven插件，从而影响Maven的行为，破坏构建的稳定性。
·项目所包含的代码已经全部提交到版本控制系统中。项目已经发布了，可源代码却不在版本控制系统中，甚至丢失了。这意味着项目丢失了某个时刻的状态，因此这种情况必须避免，版本发布的时候必须确保所有的源代码都已经提交了。
只有上述条件都满足之后，才可以将快照版本更新为发布版本，例如将1.0-SNAPSHOT更新为1.0，然后生成版本为1.0的项目构件。
不过这里还缺少一步关键的版本控制操作。如果你了解任何一种版本控制工具，如Subversion，那就应该能想到项目发布与标签（Tag）的关系。版本控制系统记录代码的每一个变化，通常这些变化都被维护在主干（Trunk）中，但是当项目发布的时候，开发人员就应该使用标签记录这一特殊时刻项目的状态。以Subversion为例，日常的变更维护在主干中，包含各种源码版本r1、r2、…、r284、…。要找到某个时刻的项目状态会比较麻烦，而使用标签就可以明确地将某个源码版本（也就是项目状态）从主干中标记出来，放到单独的位置，这样在之后的任何时刻，我们都能够快速地得到发布版本的源代码，从而能够比较各个版本的差异，甚至重新构建一个同样版本的构件。
因此，将项目的快照版本更新至发布版本之后，应当再执行一次Maven构建，以确保项目状态是健康的。然后将这一变更提交到版本控制系统的主干中。接着再为当前主干的状态打上标签。以Subversion为例，这几个步骤对应的命令如下：
至此，一个版本发布的过程完成了。接下来要做的就是更新发布版本至新的快照版本，如从1.0到1.1-SNAPSHOT。