什么是软件版本？
发布: (2026年2月16日 GMT+8 18:03)
4 分钟阅读
原文: Dev.to
Source: Dev.to
我曾经以为软件版本只是每次更新后递增的数字。
为什么会从 v1.1 变成 v1.2？
为什么会突然跳到 v2.0？
开发者那天只是想要戏剧化吗？
后来有一天，在构建一个小应用时，我终于恍然大悟。
第一次发布
想象一下，你和我一起构建一个叫 TaskNest 的简单应用。
它可以创建任务并标记完成。没有花哨的功能。
我们自豪地发布它：
v1.0.0
第一个 “1” 充满力量。它在说：
“这是真实的。这是稳定的。这已经准备好了。”
后面的零？它们只是表示目前没有额外的变化。
这种格式实际上遵循一种叫做 Semantic Versioning 的简单理念。
出现了一个 bug
第二天，有人报告：
“如果我创建一个空任务，应用会崩溃。”
我们立刻修复。没有新功能。没有设计改动。只有修复。
版本变为：
v1.0.1
只有最后一位数字变化，表示：
“放轻松。没有新内容。只是一次小修复。”
如果我们再修复另一个小问题：
v1.0.2
小修复 = 小数字变化。
新功能的加入
一周后，用户提出：
“我们能给任务添加截止日期吗？”
这不是修复，而是增长。我们添加了截止日期，其他功能保持不变。
于是变成：
v1.1.0
中间的数字增加，低声说：
“有新东西来了。”
后来我们又加入了分类：
v1.2.0
更多功能，仍然安全，仍然兼容。
重大的决定
几个月过去了，应用不断壮大。于是我们决定重新设计任务的内部存储方式。
- 旧的保存数据将无法使用。
- API 发生了变化。
- 使用我们集成的开发者必须更新代码。
这一次影响重大，所以我们发布：
v2.0.0
从 1 跳到 2 并不是出于自负，而是因为影响。它是我们向世界传达的方式：
“小心。这可能会导致破坏。”
就是这样
这就是版本控制：三个数字，三种信号。
- 最后一个数字 → 小修复
- 中间的数字 → 新功能
- 第一个数字 → 破坏性更改
这不是随意的，而是沟通。
当你看到 v2.1.3 时，你看到的不仅是数字——而是历史。
现在，每当我发布新东西时，我不再问：
“我该选哪个数字？”
我会问：
“我改变了多少故事？”