为什么要做产品版本迭代管理

一款产品从无到有，从孵化到呱呱坠地，需要经历了一个完整的生命周期，这里面包括：产品战略、产品市场、产品规划、产品需求、产品开发、产品上市、产品市场管理总共7个部分；产品管理则是对产品生命周期进行管理；当产品上市发布后，随之而来的每次更迭，修补，新增都是为了产品更加丰满、健壮、具备竞争力；所以，产品管理中对产品每次版本的定义显得尤为重要，版本的定义能够清晰的了解每次产品迭代背后的目标和价值，而产品版本编号的变化是产品生命线上每个重要的里程碑，它记录了产品特性的变化，子产品和子产品的关系变化，产品修复结果的变化等等；好的产品版本管理容易阅读，方便记忆，能够明晰各类关系，糟糕的产品版本管理会让你发现掉进深渊，落入陷阱。当你被版本锁定或版本穿插所阻挠而不能容易地让你的项目顺利前进时，你就身处依赖地狱中了。

基本原则

如果产品版本依赖定义得过于松散，你难免会被版本穿插所伤，因此，用一组简单的规则和要求来约束版本号的分配和增长规则，你必须预先定义好自己的公共API，这可以通过文档定义或代码强制要求来实现。无论如何，这套API的清楚明了是十分重要的。一旦你定义了公共API，你就可以通过修改相应的版本号来通知大家你的修改。

版本号格式：X.Y.Z（主版本号，次版本号，补丁版本号）

修复Bug但不影响API增长补丁版本号；

API保持向下兼容的增加/修改时增长次版本号；

进行不向下兼容的修改时增长主版本号。

产品版本命名规范

1、使用语义版本命名的软件系统必须定义一套公共API。这套API可以是在代码中申明或是用严格的文档定义。不管怎样做，它都应该清楚明了。

2、正常的版本号必须使用X.Y.Z的形式并且X/Y/Z是非负整数。X是主版本号，Y是次版本号，Z是补丁版本号。版本号每次必须只能增长1。例如：1.9.0->1.10.0->1.11.0。

3、当主版本号增长时，次版本号和补丁版本号必须清零。当次版本号增长时，补丁版本号必须清零。例如：1.1.9->2.0.0，2.1.7->2.2.0。

4、一旦发布了具有版本的包，那个版本的内容必须不能再更改。任何修改必须发布成一个新版本。

5、主版本号0 (0.y.z)是用来进行初始开发时使用的。任何东西都可能在任何时候改变。公共API此时应该被认为是经常变动的。

6、版本1.0.0开始定义公共API。这个版本及以后的版本号的增长方式将依赖于公共API以及它如何变化。

7、如果单一子产品有任何向下兼容的bug修复发生，补丁版本号Z (x.y.Z | x > 0)必须增长1。“bug修复”被定义为内部进行的修复非正常行为的修复工作。

8、如果单一子产品进行了新的并且向下兼容的公共API添加、优化、修改，次版本号Y (x.Y.z | x > 0)必须增长1。如果任何公共API被标记为“过期”，次版本号必须增长1；如果有大量的新功能或改进在内部代码中发生，次版本号可以增长1；这其中也可以包含补丁级别的修改。当次版本号增长时补丁版本号必须清零。

9、如果单一子产品对公共API有任何向下不兼容的修改，或者两个及两个以上子产品同时发布新特性，或者主产品开辟新业务模式，主版本号X (X.y.z | X > 0)必须增长1。这其中也可以包含次版本和补丁版本级别的修改。当主版本号增长时次版本号和补丁版本号必须清零。

如何书写并管理产品版本

样例：

本次更新

发布时间：yymmdd

产品版本为vx.y.z；

版本说明：简要概括本次产品迭代的目标和需要达到的效果；

【全新内容】

1.新增XX模块1/功能1，达到XX效果/目的；

2.新增XX模块2/功能2，达到XX效果/目的；

【产品优化】

1.优化现有XX模块1/功能1，改进了/整合了XX体验/操作/展示，达到XX效果/目的；

2.优化现有XX模块2/功能2，改进了/整合了XX体验/操作/展示，达到XX效果/目的；

【修复内容】

1.修复XX模块1/功能1，增强了/整合了XX体验/操作/展示，达到XX效果/目的；

2.修复XX模块2/功能2，增强了/整合了XX体验/操作/展示，达到XX效果/目的；

产品计划

产品版本为vx.y.z，产品状态，项目代号：XXX（内容描述，通常是产品方向，是业务项目或者是平台建设及优化）；