2.3.9之后再改就是2.4.0？产品的版本号是如何确定的？什么时候会多加一个？每当一个产品更新是，你是否也有这样的疑问？本文作者依据工作中项目实践的所思所想，并结合案例等分享了产品迭代过程中需要注意的关键点，供大家一同参考和学习。
随着互联网行业的发展越来越快，几天一次大更新，无时无刻不在小更新的产品越来越多，但我们经常会见到一些公司对于版本的管理及其混乱。一次我的一个码农朋友跟我讲他在的那家公司完全不理解版本是什么，修复一个bug更新一个弹窗都会当做版本更新，在上线一个月以后已经把APP的版本更新到了2.3.0。
开始听到这个事情时我还当做是一个笑话，后来发现这种情况其实并不罕见。
常识类概念
常见的版本号命名规则
在这里先简单的和大家聊一下关于版本的常见命名规则和几种类型。
在大部分情况下常见的版本号是三段式的，即X.Y.Z我们用X来表示大版本号，一般当产品出现重大更新、重写、不再向后兼容的情况时我们会在X上加1，当X是0的时候我们默认为开发或测试阶段。当X增加1时我们会把后面的Y.Z清零。我们用Y来表示功能更新，同理当Y增加1时我们也会将后面的Z清零。Z则表示小修改，如我们修复了一个bug，页面的UI布局做了修改调整时都会增加Z，但是当Z等于10时我们不增加到Y，而是写成X.Y.10，之后的更新为X.Y.11。
在不同的项目也会有不同的命名规则，这里只做一种常见的命名规则分享，并不能代表全部。
除了版本号之外还会有一些修饰的词，比如：alpha:内部版本beta:测试版rc:即将作为正式版发布lts:长期维护
作为一个产品很多时候我希望大家名词，讲人话。奈何身边总会有人为了显示自己是互联网老鸟，能说缩写的绝对不会说中文。为了避免新人被这些黑话唬住，还是简单的拓展一下。
思考阶段
首先我们作为产品很多时候也要对功能和项目的排期负责，在大家都在小步快跑做产品时，如果一个产品对于版本的管理理解深刻的话，可以省去不少麻烦。
在版本开发前我们要计划出这一版本我们要做什么，这会让我们明确我们需要多少人手，需要多长时间来完成这次的计划。在版本开发时我们要明确这一版本我们要集中解决哪些问题，达成什么样的目标，这会让我们有共同的目标和清晰的侧重点。在版本开发后我们要明确上一版本中我们需要重点