软件工程35-版本发布：软件上线只是新的开始

说到版本发布，对于很多开发人员来说，觉得是很简单的一个事情，就是将程序编译打包部署，但实际发布的时候，却经常出现发布错版本的问题，或者是发布前修改了一点代码导致上线出现 Bug 的情况发生。

而版本发布对于很多项目管理者来说，又是一个很纠结的事情，觉得还有很多功能没完成，很多 Bug 还没改完，害怕用户负面评价，结果时间一拖再拖，迟迟无法上线。

所以今天我将带你一起学习一下如何做好版本发布，保障好发布产品的质量。

关于软件版本

在讨论这个话题之前，我们需要了解“版本”的含义。也许你已经知道版本的含义，但是这里还是有必要明确一下，因为在不同的语境下，版本的含义也有所不同。比如产品经理会对开发人员说：“这个功能我们会放到下个版本中实现”，开发人员会对测试人员说：“这个 Bug 在昨天的版本中已经修复了”。

这里产品经理说的“版本”是指特定功能集合，开发人员说的“版本”是指某一次程序的构建结果。也就是说对软件版本来说，包含两部分含义，一部分代表特定功能集合，一部分代表某一次特定的代码构建结果。

为了明确标识软件版本，需要对版本进行编号。目前业界在软件版本的命名上，通常会采用以下方式：

主版本号 . 子版本号.[. 修正版本号.[构建版本号]]

比如说：1.2.1、2.0、3.0.1 build-123。

其中主版本号和子版本号用来标识功能变化，小的功能变化增加子版本号，大的功能变化增加主版本号。修正版本号则表示功能不变化的情况下修复 Bug，而构建版本号表示一次新的构建，这个通常由编译程序自动生成。

团队中对版本有了清晰的定义和良好的版本编号，在讨论版本时，你就可以根据版本号清楚地知道应该有哪些功能，属于哪一次的构建结果。在修复 Bug 或者增加功能时，开发人员也能清楚地知道代码应该加入哪个版本。在验证 Bug 时，测试人员就可以知道应该在哪个版本中验证 Bug 有没有被修复。

版本发布前，做好版本发布的规划

回到前面的问题，为什么有的项目管理者会在发布前感觉没准备好，害怕上线发布呢？根源上，他们还是对于功能和质量没有信心，担心发布后获得负面的评价。

而实际上，并不代表你需要完成所有的功能，或者没有任何 Bug，有一个完美的版本才能上线。毕竟追求完美是没有止境的，这世界上也不存在完美的软件，很多著名的软件，比如 Windows、Office、iOS 都免不了在发布后还要打补丁。