SNAPSHOT 版本 VS RELEASE 版本

SNAPSHOT 版本 VS RELEASE 版本

Maven 仓库分为两种，Snapshot 快照仓库和 Release 发行仓库。Snapshot 快照仓库用于保存开发过程中的不稳定 SNAPSHOT 版本，Release 发行仓库则用来保存稳定的 RELEASE 版本。

Maven 会根据模块的版本号（pom.xml 文件中的 version 元素）中是否带有 -SNAPSHOT 来判断是 SNAPSHOT 版本还是正式 RELEASE 版本。带有 -SNAPSHOT 是SNAPSHOT（快照）版本，不带 -SNAPSHOT 的就是正式 RELEASE（发布）版本。

SNAPSHOT 版本和 RELEASE 版本区别如下表。

区别	SNAPSHOT 版本	RELEASE 版本
定义	版本号中带有 -SNAPSHOT	版本号中不带有 -SNAPSHOT
发布仓库	Snapshot 快照仓库	Release 发行仓库
是否从远程仓库自动获取更新	在不更改版本号的前提下，直接编译打包时，Maven 会自动从远程仓库上下载最新的快照版本。	在不更改版本号的前提下，直接编译打包时，如果本地仓库已经存在该版本的模块，则 Maven 不会主动去远程仓库下载。
稳定性	快照版本往往对应了大量带有时间戳的构件，具有不稳定性。	发布版本只对应了唯一的构件，具有稳定性。
使用场景	快照版本只应该在组织内部的项目中依赖使用。	Maven 项目使用的组织外的依赖项都应该时发布版本的，不应该使用任何的快照版本依赖，否则会造成潜在的风险。
发布前是否需要修改	当项目经过完善的测试后，需要上线时，应该将项目从快照版本更改为发布版本	不需要修改

SNAPSHOT-优点：

同一个SNAPSHOT版本的依赖可以多次发布（deploy）到仓库中，即同一个SNAPSHOT版本的依赖可以在仓库中存在多份，其中HEAD总是指向最新的快照，对外界可见的一般也是最新版，这种给人的假象是新的覆盖了老的，从而使得使用SNAPSHOT依赖的客户端可通过重新构建就可以拿到最新的代码（有时候需要-U强制更新）。例如：A-->B-1.3.8-SNAPSHOT（理解为A依赖了B的1.3.8-SNAPSHOT版本），那么B-1.3.8-SNAPSHOT更新之后重新deploy到仓库之后，A只需要重新构建就可以拿到最新的代码，并不需要改变依赖B的版本。由此可见，这样达到了变更传达的透明性，这对于开发过程中的团队协作的帮助不言而喻。

SNAPSHOT-缺点：

SNAPSHOT版本的依赖因为存在变更传达的透明性的优势而被赏识，有很多团队索性直接使用SNAPSHOT到生产环境中，这样对于变更直接生效，很方便。但是作为技术人员的我们其实应该很严谨地看待变更传达的透明性，变更就意味着风险，透明性更是把风险彻底隐藏了起来，生产环境中存在这样的现象更是心惊胆战。例如：A-->B.1.0.3-SNAPSHOT，B对一个A使用的功能实现进行了调整，直接发布到仓库，A重新构建或许就会失败，更糟糕的是构建成功，运行时异常。这个时候A甚至完全没有代码变更就突然失败了，会带来更多的困惑。