起初，我不太理解版本在程序开发中起到怎样的作用。直到上周末与一个朋友聊天时，他的开发工具 Webstorm 突然罢工，需要激活，我将之前我的激活方式告诉了他，但他回应激活失败，询问之下才知，他的 Webstorm 使用的是 2016.1 版本，而我给他的激活方式适用 2017.2 版本，我问他为什么不升级工具，他回答只要能用不就成了，干嘛要升级？我一时语塞，不知该如何回答他。回过头我细想了一下，觉得还是有必要升级的，本文主要介绍一下几点。

为什么要升级？

版本升级规范？

那么多程序，那么多版本，如何记忆？

一、为什么要升级？

1. 开源社区与 Issue

之前做过一个项目，当时使用 bootstrap-fileupload 组件处理文件上传，发现中文显示总是乱码。当时脑子里有个思维定式：官方的东西怎么可能会出错呢，肯定是我自己哪里写的有问题？去官方文档将所有属性都检查了一遍，网上也搜了下问题都没能找到答案。最后在源码里 debugger 一步步找问题，发现是由于 windows 上记事本的编码为 'ANSI'，而 bootstrap-fileupload 设置中文编码 'gbk' 二者并不匹配导致，修改之后就恢复正常了。我想将这个 Bug 提给官方人员，但不知道怎么联系他们，我甚至在搜索引擎里搜索 bootstrap-fileupload 的官方邮箱。（现在想想有点傻乎乎的）

今年 6 月份接触 github，第一次感受到 开源社区 的含义：dva 是一个基于 React 的前端框架，公司项目选型时决定用它，技术总监便给了我它的 github 地址让我去读一读它的文档。

在这里，我才晓得原来 dva 的源码竟然是触手可及的，而不再是生硬的 dva.min.js 文件。如果发现 Bug，可以去 Issue 库里提问，官方人员会验证之后并解决的。在 Issue 库里你不仅可以提出 Bug，还可以帮忙解决 Bug 然后将修改的内容 Pull Request 给官方人员。Issue 库还有个巨大的好处就是遇到问题去里面找，基本上你遇到的问题其它人都有遇到并解决过，这效率比在百度搜索问题准确性不知高了多少倍。

Dva github 页面

现在，比如在 [email protected] 里发现了一个 Bug，在开源社区里给官方提了一个 Issue，官方修复后并发布了新版本 [email protected]，只需要下载最新的版本即可愉快的使用，而不是去修改源码。

注：并不是所有项目都是开源的，开源的项目也并不一定就把代码放在 Github 上，我找了下 jquery 社区是在 Github 上的，Bootstrao-fileupload 好像并没找到。

2. 软件需要持续升级

软件的每一次升级，或修复之前功能 Bug，或新增新的功能，或在优化了性能，让程序跑的更快。啥？你还不想更新？当别人的微信升级后可以同时发送多张照片，你没升级的版本只能一张张地发送照片。当别人家的 Webstorm 更新之后启动只花了 5 s，你使用老的版本启动却花了 10 s。你还有什么理由不更新。

程序或软件并不是一次性的东西，开发完成就放那不管不顾了。这是个持续改进，持续完善的过程。版本就是软件更新的历史节点。一个好的程序会指定良好的版本规则，定期发布新版本，做一些功能上的改进，并将做了哪些修改告诉明确的告知客户。

手机软件更新

二、版本升级规范？

对于客户来说，不需要关心软件是怎么升级的，他们只关心软件更新了哪些内容，好不好用。

对于开发人员来说，我们制定版本号，有条不紊的定期升级。如果制作版本号的规则混乱，在管理版本的时候将会及其痛苦。所以，我们遵循着相关规范。

1. 版本号

在上图中，可以看到 6.4.7 -> 6.4.8，这是将头条@6.4.7 版本升级到 @6.4.8 版本。规定版本号由三部分组成，按照顺序分别为主版本号.次级版本号.修订号。

修订号何时变化？ 当修复一两个 Bug，改动很小时，将修订号 +1；
次级版本号何时变化？ 当新增一些功能，如头条新增一个栏目时，将次级版本号 +1，修订号置 0，就变成了 6.5.0，此时的改动不容忽视，但也不是很大；
主版本号何时改变？ 当做了很大的改变，如：变动了头条栏目的布局，用户再登录进去时操作体验完全改变时修改主版本号+1，此时次级版本号和修订号置0，变成了 7.0.0。

在开发人员开发一个新的程序时，建议命名第一个版本号为 0.1.0 ，以后按照规则依次递增，第一个 可用的发行版本 将主版本号升级为 1.0.0。

2. 版本阶段

头条新闻对于用户来说叫做软件，对于开发人员来说叫做程序，以下统称程序。

光是看版本号，可能对于程序处于什么状态并不能完全掌握，此时还需附带版本阶段相关英文单词来附加说明，格式：版本号-版本阶段英文单字。

如看到 [email protected] 就知道 dva 的版本号为 1.3.0，当前处于 公测阶段，本身还存在 Bug，给部分用户体验，用户提出 Bug 并全部修复完成后才能正式发布。

版本号附带英文字母

程序版本阶段对应英文如下，大家遵守规范，看到英文单词就这个这个版本当前处于什么阶段。

alpha 内测阶段：该阶段主要实现程序功能，通常只在内部开发人员之间交流，该阶段存在 Bug 较多，待完善。
beta 公测阶段：该阶段较 alpha 来说修复不少 Bug，但仍存在隐藏问题。由于内部人手有限，先发布该阶段版本让广大发烧友用户们先做体验，发现问题，解决问题，不断完善。比较熟悉的就如小米发烧友就会很积极的测试功能。
rc 候选阶段：该阶段基本解决完 beta 阶段的所有 Bug，算是比较完善的一个版本了，可以发布给所有用户使用。该阶段与 release 阶段相差无几，那为什么不直接忽略此阶段版本呢？

我猜测应该还是考虑一个稳妥的问题。比如：固定 20 号发布一个 release 版本，15 号的时候就已经开发完成并测试通过进入 rc 候选阶段，如果剩下五天不出叉子，那么这个 rc 版本就是后面的 release 版本，万一运气不好，又测出 Bug，那么就修改发布 rc2 版本作为新的候选版本。
release 正式发行版：啦啦啦啦，正式上线版本，给广大用户使用，此时要是再有明显 Bug 是及其影响用户体验，损失用户量的，该阶段可以算是完全体了。

当然，对于用于来说，频繁的更新版本也是一件很痛苦的事。比如我们使用 node，我们就是用户，node 官方要是隔三差五就更新一次版本，我们在项目中也需要被迫更新 node 版本，这是难以忍受的。于是，node 推出里两个版本阶段可供选择。

LTS（Long-Term Support）长期支持版本：该阶段相当于上面的 release 版本，基本没啥大 Bug，可供 node 开发人员长期使用，大概 18 个月才会有一次大更新，也就是说安装 LTS 版本之后就不会频繁更新。
Current 当前阶段：在 LTS 阶段，如果 node 再添加新的特性或者修复 Bug 怎么办？统统放到 Current 阶段里，该阶段并不稳定，api 经常会变，对于开发人员来说，并不推荐使用。等到 18 个月会将该阶段升级为 LTS 稳定阶段。

Node 官方主页

三、那么多程序，那么多版本，如何记忆？

在前端开发中，使用的每个前端框架（Vue or Angular or React or Dva.....）、UI 框架都有自己的版本控制，如何去知道什么框架升级到什么版本有什么新的功能呢？

1. 开源社区

市面上框架那么多，你的项目肯定不是每种都用的吧，着重关注项目中使用到的程序版本问题。如我的项目中使用 dva、ant-design 、roadhog 、微信小程序，还有一些开源项目，这些项目并不会每天都有更新，官方勤快一点的每周固定更新一次，懒一点的半个月，一个月左右更新一次。所以我一般每周一去开源社区逛一逛，看看最新动态，社区里会有更新日志，没有日志的可以去 Issue 库里看看又出现了什么新的问题。

2. 开源中国网站

开源中国社区首页有一个板块专门介绍软件更新资讯，里面有更新的软件版本，更新内容，并且涉及面极广。每天逛一逛再也不用担心拉下什么重要更新事项了。

开源社区软件更新板块

程序员应该重视版本控制