程序员应该重视版本控制

2019独角兽企业重金招聘Python工程师标准>>>

起初，我不太理解 版本 在程序开发中起到怎样的作用。直到上周末与一个朋友聊天时，他的开发工具 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 库还有个巨大的好处就是遇到问题去里面找，基本上你遇到的问题其它人都有遇到并解决过，这效率比在百度搜索问题准确性不知高了多少倍。

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

注： 并不是所有项目都是开源的，开源的项目也并不一定就把代码放在 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. 版本阶段

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

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

如看到 dva@1.3.0-beta 就知道 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 稳定阶段。

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

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

1. 开源社区

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

2. 开源中国网站

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

转载于:https://my.oschina.net/dkvirus/blog/1589150