Maven SNAOPSHOT 版本能一直更新，而 RELEASE 版本同一个版本号的包只能上传一次

Maven 为什么要区分发布版本和快照版本

试想一下这样的情况，小张在开发模块 A 的 2.1 版本，该版本还未正式发布，与模块 A 一同开发的还有模块B，它由小张的小李开发，B 的功能依赖于 A。在开发的过程中，小张需要经常将自己最新的构建输出，交给小李，供他开发和集成调试，问题是，这个工作如何进行呢？

如果不停更新版本 2.1.1、2.1.2、2.1.3.... 首先，小张和小李两人都需要频繁地更改 POM，如果有更多的模块依赖于模块
A，就会涉及更多的 POM 更改；其次，大量的版本其实仅仅包含了微小的差异，这样也会造成为版本号的滥用

Maven 的快照版本机制就是为了解决上述问题。在该例中，小张只需要将模块 A 的版本设定为2.1-SNAPSHOT，然后发布到私服中，在发布的过程中，Maven 会自动为构件打上时间戳。比如：2.1-20091214.221414-13 就表示 2009 年 12 月 14 日 22 点 14 分 14 秒的第 13 次快照。有了该时间戳，Maven 就能随时找到仓库中该构件 2.1-SNAPSHOT 版本最新的文件。这时，小李配置对于模块 A 的 2.1-SNAPSHOT
版本的依赖，当她构件模块 B 的时候，Maven 会自动从仓库中检查模块 A 的 2.1-SNAPSHOT 的最新构件，当发现有更新时便进行下载。默认情况下，Maven 每天检查一次更新（由仓库配置的 updatePolicy 控制），用户也可以使用命令行 -U 参数强制让 Maven 检查更新，如：mvn clean install-U

基于快照版本机制，小张在构建成功之后才能将构件部署至仓库，而小李可以完全不用考虑模块 A 的构建，并且他能确保随时得到模块 A 的最新可用的快照构件，而这一切都不需要额外的手工操作

快照版本的不稳定性

当项目经过完善的测试后需要发布时，就应该将快照版本改为发布版本。例如，将 2.1-SNAPSHOT 更改为 2.1，表示该版本已经稳定，且只对应了唯一的构件。相比之下，2.1-SNAPSHOT 往往对应了大量带有不同时间戳的构件，这也决定了其不稳定性

快照版本只应该在组织内部的项目或模块间依赖使用，因为这时，组织对于这些快照版本的依赖具有完全的理解及控制权。项目不应该依赖于任何组织外部的快照版本依赖，由于快照版本的不稳定性，这样的依赖会造成潜在危险。也就是说，即使项目构建今天是成功的，由于外部的快照版本依赖实际对应的构件随时可能变化，项目的构建就可能由于这些外部的不受控制的因素而失败