平时我们见到的软件，特别是面向开发者的软件或者开源框架等，都会以一个英文缩写来标识当前版本的级别，所以我们应当根据使用软件的具体需求场景来对这些版本进行选择。
- Alpha：是内部测试版,一般不向外部发布,会有很多Bug.一般只有测试人员使用。
- Beta：也是测试版，这个阶段的版本会一直加入新的功能。在Alpha版之后推出。
- RC：(Release Candidate) 顾名思义， 用在软件上就是候选版本。系统平台上就是发行候选版本。RC 版不会再加入新的功能了，主要着重于修复测试中发现的缺陷。
- GA : General Availability，正式发布的版本，国外通常用 GA 来标识 release 版本，GA 版本是开发团队认为该版本是稳定版（有的软件可能会标识为 Stable 版本或者 Production 版本，其意思和 GA 相同），可以在较为关键的场合使用，比如生产环境。
所以，如果对软件的稳定性要求极高，但是对实时添加的新特性没有需求的话，GA 版本就是最合适的选择了。
在使用 maven 过程中，我们在开发阶段经常性的会有很多公共库处于不稳定状态，随时需要修改并发布，可能一天就要发布一次，遇到bug时，甚至一天要发布N次。maven 的依赖管理是基于版本管理的，对于发布状态的 artifact，如果版本号相同，即使我们内部的镜像服务器上的组件比本地新，maven也不会主动下载的。如果我们在开发阶段都是基于正式发布版本来做依赖管理，那么遇到这个问题，就需要升级组件的版本号，可这样就明显不符合要求和实际情况了。但是，如果是基于快照版本，那么问题就自热而然的解决了，maven 总会选择“最新”一个快照来使用。
有的团队会选择直接在线上使用 SNAPSHOT 版本的，这样对于变更直接生效，很方便。但是这样也会有很大的潜在风险，生产环境中更是不能允许这样的风险存在。例如：A 软件依赖于B 软件的 3.2.1-SNAPSHOT 版本，B 软件的团队对一个 A 使用的功能实现进行了调整，但并没有考虑到适配之前的版本，然后直接发布到仓库，这时 A 要么会构建失败，要么会在运行时产生异常，然而 A 团队也许很久才会发现是 B 软件的一次小小变更导致的问题。
不稳定的依赖会直接导致系统的不稳定，所以应当在生产环境中尽量使用 RELEASE 版本的依赖，这样能规避很多不必要的风险。
个人博客同步更新，获取更多技术分享请关注：郑保乐的博客
