版本管理介绍

项目的开发是长期的过程。这个过程里有每个项目的生命周期和各个功能的里程碑。一般会把这些周期和里程碑确定成一个个的版本，以便对整个项目实行历程的管理和阶段目标的控制。那怎样科学地管理项目的版本呢？接下来就讨论这个问题。

在正式进行介绍前，有必要澄清一下这两个概念：版本管理和版本控制。

版本管理是指对项目的整体版本的演变过程进行管理，例如，从 1.0 到 1.1，再到 2.0 等。版本控制是借助第三方的版本控制工具，追踪管理项目文档（包括代码）的每一个变更。

接下来主要介绍的是版本管理，而不是版本控制，请读者注意区分版本管理和版本控制。

专业术语

为了方便理解，先了解相关的专业术语，也就是概念。

1. 快照版本

在项目开发过程中，为了方便团队成员的合作，解决模块间相互依赖和时时更新的问题，用户对每个模块进行构建的时候，输出的临时性版本叫快照版本。这种版本定位的构件文件会随着开发的进展不断更新。

同时 Maven 对同一个快照构件的依赖也会同步更新，使团队内部相互用到的依赖都是最新的。

2. 发布版本

项目开发到一定的阶段后，就需要向团队外部发布一个比较稳定的版本。这个版本构件所对应的构件文件是固定的。就算后期有更多的功能要继续开发，完成后也不会改变当前发布版本的内容，这样的版本叫发布版本。

3. 版本管理关系

在项目开发过程中，团队内部会随着项目的进展发布最新的快照版本。但是开发到一定的阶段，需要将快照版本定位成一个发布版本对团队外部进行发布，同时，在这个定位版本的基础上进行二次开发，开发过程中又形成新的快照，到一定阶段后，再发布一个定位的发布版本，以此重复进行，直到最后项目完成。

这个过程中快照版本和发布版本的切换管理就是版本管理。也就是说，版本管理关系的一个核心问题就是要科学地解决快照版本和发布版本之间的切换问题。

理想的发布版本，应该是在项目进展到一个比较稳定的状态。这种稳定状态包括源代码的状态和构件的状态，所以一般构建一个稳定版本的条件有以下几个方面。

1）所有的测试案例应该全部通过。这点可以理解，自己的测试案例都不能通过，说明有漏洞。发布这种带有明显漏洞的版本是没有意义的。

2）项目中没有配置任何快照版本的依赖。发布版本与快照版本最显著的区别就是稳定。如果自己包含有对快照构件的依赖，依赖的基础都不稳定，怎么能谈得上自己的稳定呢？

3）项目中没有配置任何快照版本的插件。同上面的道理一样。

4）项目中所有的文档（包含代码）都要提交到版本控制系统。一个稳定版本的发布，不仅表示项目进入到了一个相对稳定的阶段，而且还必须保证相关的文档能齐备，以便以后能准确返回到这个阶段。

如果要发布的文档没有全部集中提交到版本控制系统中，意味着一不小心文档就会残缺，这样的版本就没法回滚。

版本号的约定

为了方便团队交流，Maven 将版本号约定为四个部分，即主版本、次版本、增量版本和里程碑版本，按如下格式共同形成一个版本号。

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

• 主版本：表示项目重大架构的变更。比如 Struts1 和 Struts2，它们的架构体系都不同；JUnit4 和 JUnit3，一个全面支持注解，另一个就不支持。
• 次版本：表示有较大的功能增加和变化，或者全面系统地修复漏洞。
• 增量版本：表示有重大漏洞的修复。
• 里程碑版本：表明一个版本的里程碑（版本内部）。这样的版本同下一个正式版本相比，相对来说不是很稳定，有待更多的测试。

需要注意的是，不是每个版本号都必须由这四个部分组成，有些版本号就可以没有增量版本和里程碑版本。

主干、分支、标签

1）主干：项目开发的主体，也是主线、关键历程。从这里可以获取项目的最新代码和绝大部分的变更历史。

2）分支：从主线某个点分离出去的一段分支。在一个特别时间点的时候，既要保持项目的总体（主线）进度，又要同步修改某些重要漏洞、或实现特殊功能、或实验性开发，就可以创建一个分支独立进行。分支达到预期效果后，需要将分支里面的变更合并到主线中去。

3）标签：用来标记分支和主干进展到某个状态的点，代表项目进展到某个阶段或某个相对比较稳定的状态。实际项目中，这种状态往往就是版本发布的状态。