项目里谁是第一版本主？一招教你快速区分清楚！

今天来聊聊我们搞第一个正式版本时候的事儿，就是所谓的“第一版本主”。

我们自己捣鼓项目，根本没想过啥版本号。代码写完了，或者改了点就直接覆盖掉原来的，或者随便起个带日期的文件名，比如“项目最终版”、“项目最终最终版_改”、“项目_20231026”这种，估计好多人都这么干过，特别乱。

后来项目慢慢成型了，开始要给内部其他人用，甚至有可能要给外边的人试试。这时候问题就来了，你给别人一个文件，下次更新了，你怎么告诉人家这是新是旧？哪个是哪个？总不能还靠文件名瞎猜。而且几个人一起开发，你改了他改了合并的时候也容易乱套。这时候就觉得，得有个正规的搞法了。

琢磨版本号

我当时就去网上扒拉了一下，看看别人是怎么弄版本号的。嚯，说法还挺多。有说用三个数字的，主版本号.次版本号.修订号，像 1.0.0 这种。还有说后面可以加编译号或者日期啥的，搞得更复杂。还有提到什么“语义化版本”，听着就头大。

当时我们团队也就几个人，项目也算不上特别巨大。我就想，别整那些虚头巴脑的，搞那么复杂干嘛咱们目的是要区分版本，让人一眼看明白新旧，知道大概改了多少东西就行。

拍板，就用最常见、最简单的那个三段式：X.Y.Z。

定下第一个“1”

那为啥第一个版本是“1”开头，也就是所谓的“主版本号”定为1？

这事儿没啥高深的。你想，这是我们项目第一次正式对外发布，或者说，是第一个我们觉得功能基本完整、比较稳定、可以拿出来见人的版本。它代表着从0到1的突破，是个里程碑。用“1”作为开头，感觉最有仪式感，也最符合“第一个正式版”这个身份。

于是我们就把第一个可以交付的版本，定为 1.0.0。

• 1：代表这是第一个大版本，主要功能都实现了。
• 0：代表这是这个大版本里的第一个次要版，还没啥大功能补充。
• 0：代表这是这个次要版里的第一个修订，刚发布，没修复啥 bug。

这个 1.0.0 不是随便拍脑袋的，是内部我们几个人一起测了好几轮，把发现的比较明显的问题都修掉了，觉得“这玩意儿能跑起来，核心功能没问题了”，才给它冠上这个名号的。

落地执行

定了版本号规矩就好办了。我们约定

以后要是加了新功能，或者有比较大的改动，但不至于颠覆整个项目，那就升级第二个数字，比如变成 1.1.0。

如果只是修修补补，改了点小 bug，那就升级第三个数字，比如 1.0.1。

只有等项目做了翻天覆地的变化，比如整个架构都重写了，那才会考虑把第一个数字加一，变成 2.0.0。

具体操作上，我们也没用啥特别高级的工具。就是在代码的关键地方（比如一个全局配置文件或者常量定义里）写上当前的版本号。然后每次编译打包或者发布的时候，确保这个版本号是对的。在我们的项目管理工具或者简单的更新日志里，也记下这个版本号对应的改动。

就这么简单，没搞太复杂。小团队嘛沟通起来方便，吼一嗓子大家都知道了。重要的是先把规矩立起来，从混乱变有序。

我们的“第一版本主”就这么诞生了。主要就是为了解决混乱问题，选了个最简单直接的方式，定了 1.0.0，然后大家照着这个规矩往下走。实践下来，效果还行，至少比以前瞎搞强多了。