功能快速开发中的基本概念

开发版本

开发过程由功能进行细分，不同功能在不同的 Git 分支上开发，产生不同的开发版本。

开发分支的命名格式类似 dev-<feature> 。

开发版本带 dev-<feature> 标签，版本号形如 <x>.<y>.<z>-dev.<featrue>.<milestone>.<number> 。其中：

比如 1.0.3-dev.compare.beta.3 表示是一个在 1.0.3 这个正式版本的基础上，专注于 compare 这项功能，到达 beta 这个开发阶段后，又递增了 3 次的开发版本。

如果又加了一些功能，这个版本号再递增一次就是 1.0.3-dev.compare.beta.4 ；
如果达到下一个开发阶段了，就变成 1.0.3-dev.compare.release.0 ；
如果开发中 1.0.3 修复了一个 bug ，变成了 1.0.4 版本。那么采用这个新版本来继续开发 compare 功能的开发版本就是 1.0.4-dev.compare.beta.3 。

一般情况下到达 release 阶段之后，开发版本的发布频率就可以大大降低了。为了避免标签太多，在一个功能达 release 阶段之后，可以把对应的标签给删了。

前瞻版本用来汇总开发中的功能，送给那些比较前卫的用户来体验。但基于前瞻版本来开发，会无法明确所依赖的功能，所以前瞻版本不用于开发。

当某个功能开发得比较成熟时，可以把这个功能的开发版本汇总到前瞻版本给大家用。最好是开发阶段达到 beta 以上，才被认为是功能开发得比较成熟。

前瞻版本应该在名叫 next 的 Git 分支上发布。将开发分支合并到 next 分支来汇总功能。

前瞻版本带 next 标签，版本号形如 <x>.<y>.<z> 。其中：

版本号中 <x> 应该是偶数。
如果一个功能的新的开发版本被汇总进来了，那递增一下 <z> ；
如果一个新功能被汇总到了前瞻版本，那么递增一下 <y> ，同时 <z> 重置为 0；
如果某次汇总包含一些破坏性更新，版本号可以从更高的 <x>.0.0 版本开始。比如在 2.3.9 的前瞻版本上汇总了一个叫 deleteAllAndGiveEverythingUp 的包含破坏性更新的功能，那这个前瞻版本可以叫 4.0.0 。

与前瞻版本类似，正式版本用来汇总成熟的功能。如果一个功能到达了 release 开发阶段，那就可以把这个功能合并到正式版本发布。

前瞻版本应该在 Git 仓库的主分支上发布，比如 master 分支。将开发分支合并到主分支来汇总功能。

正式版本的标签是 latest ，形如 <x>.<y>.<z> 。其中：

版本号中 <x> 应该是奇数。
如果一个功能的新的开发版本被汇总进来了，那递增一下 <z> ；
如果一个新功能被汇总到了正式版本，那么递增一下 <y> ，同时 <z> 重置为 0。；
如果某次汇总包含一些破坏性更新，版本号可以从更高的 <x>.0.0 版本开始。比如在 1.2.4 的正式版本上汇总了一个叫 deprecateAllApisAndKillThePackage 的包含破坏性更新的功能，那这个正式版本可以叫 3.0.0 。

当正式版本中出现 bug 时，不再通过迭代开发版本来修复，而是把 bug 的修复当成一个功能来开发。这种功能用于修复正式版本，由 fix 开头命名，比如 fixTooManyUsefulfunction 。