转载

Maven 版本管理

## Maven 版本管理

这里举一个实际例子： **1.3.4-beta-2**

Maven 的版本号定义约定是这样的：

<主版本> . <次版本> . <增量版本> - <里程碑版本>

**主版本**：表示项目的重大架构变更，可能版本之间完全不兼容。比如 Maven2 和 Maven 1相去甚远
**次版本**：表示大范围的功能增加和变化，以及bug修复。例如 Nexus 1.5 较 1.4 添加了 LDAP 的支持，并修复了很多 Bug 的修复，但从总体架构来说，没什么变化。
**增量版本**：一般表示重大 Bug 的修复，例如项目发布了 1.4.0 版本之后，发现了一个影响功能的重大 Bug，则应该快速发布一个修复了 Bug 的 1.4.1 版本。
**里程碑版本**：顾名思义，这里往往指某一个版本的里程碑。例如，Maven 3 已经发布了很多里程碑版本，如 3.0-alpha-1、3.0-beta-1 等。这样的版本与正式的 3.0 相比，往往表示不是非常稳定，还需要很多测试。

大部分情况下，项目会有主版本以及次版本，其他版本号字段视具体项目而定

主干、标签与分支

使用版本控制工具时我们都会遇到主干（trunk）、标签（tag）和 branch（分支）的概念。

举个Subversion的例子（是一个典型的例子，并不是规范）：

项目主干基本保持最新，假设项目最初版本是1.0.0-SNAPSHOT，经过一段时间后，1.0.0版本发布，这时候就需要在主干上打一个标签。
然后项目进入1.1.0-SNAPSHOT状态，大量的开发工作都在主干中，添加了一些新特性并修复了很多Bug之后，项目1.1.0发布，同样，这时候需要打另一个标签。
发布之后，然后进入1.2.0-SNAPSHOT阶段，可这个时候用户报告1.1.0版本有一个重大的Bug，需要尽快修复，我们不能在主干中修Bug，因为主干有太多的的变化，无法在短时间内侧完毕并发布，我们也不能停止1.2.0-SNAPSHOT的开发，
因此这时候可以基于1.1.0创建一个1.1.1-SNAPSHOT的分支，在这里进行Bug修复，然后为用户发布一个1.1.1增量版本，同时打上标签。当然，还不能忘了把Bug修复涉及的变更合并到1.2.0-SNAPSHOT的主干中。
主干在开发一段时间之后，发布1.2.0版本，然后进入到新版本1.3.0-SNAPSHOT的开发过程。

原文 https://segmentfault.com/a/1190000021611660

正文到此结束