软件是人类少数永远可以不完成的产品

发现一个有趣的问题。

这两周我几乎倾尽全部的业余时间，尝试开发软件。

从最开始的每天迭代10版到现在争取每天迭代1版，目前已经迭代到了59版。

我发现，软件是人类少数永远可以不完成的产品。

举个例子，比如一本书出版了，基本就定型了。一栋楼盖完了，也不会每周更新一次。

一把椅子、一台冰箱、一辆汽车，交付的那一刻，通常意味着它已经完成。

但是，软件不是这样。

它可以永远停留在路上，永远在迭代。

今天修一个 Bug，明天增加一个功能，下个月重构一次底层架构，几年之后，它甚至可能已经完全变成另一种东西。

所以软件才需要版本号。其实我一直对软件的版本号也心存疑惑，只是没有追问。

为什么有的版本号里有“beta”，而有的没有？

再比如，1.4.2 这种看起来普通的数字，到底意味什么呢？有时候会按顺序，有时候又不按顺序。

以及为什么 2.0 不一定比 1.9 更强，等等问题。

其实，版本号不是分数。它记录的是变化。

软件开发里，最常见、最规范的一套版本命名方式，就是 Semantic Versioning，语义化版本，简称 SemVer。

标准格式：MAJOR.MINOR.PATCH

例如：1.4.2

MAJOR：是主版本号，发生不兼容的大改动时升级

MINOR：次版本号，新增功能但保持兼容时升级

PATCH：修订号，修 Bug、小优化、不新增重大能力时升级

Beta 一般表示：核心功能基本成立，可以给真实用户使用，但仍然可能有明显 Bug 或调整。

其实更有意思的是 1.0。

很多人会觉得，1.0 意味着终于做完了。

恰恰相反。对软件来说，1.0 通常只是第一次正式宣告。

这个东西已经完整到，可以让别人开始依赖它了。

所以 0.9 和 1.0 之间，并不是只差 0.1。

中间隔着的是一条承诺线。从这一刻开始，你不再只是做一个实验。

你开始维护兼容性，修复问题，照顾旧用户，为过去做出的设计负责。

软件最特别的地方就在这里。

它几乎没有真正意义上的完成。只有一次又一次发布。

版本号不仅仅在记录软件。

它记录的是一个产品如何一边被使用，一边继续长大，想一个不断生长的生命体。

也同样记录着开发者的每一个灵感、脑洞、彷徨、质疑以及莫名其妙的信念。

上一次我觉得自己真正活着的刹那是在今年元旦，我立志要卡半夜0点前发稿，无论写不写的出来，一定要发。

而最近这段时间，我每天都在职场人、开发者的角色里无缝切换，每天都有无数新的问题。但我活的很开心。