软件版本号命名背后的商业逻辑

最近碰到一个实际的问题，客户对软件产品的版本号定义表示质疑，例如两个版本之间怎样才算跨版本，到底什么情况下可以免费升级，什么情况又必须付费呢？

关于为软件产品命名版本号这种做法的悠久历史，我这里就不打算展开叙述了，毕竟在维基百科上已经有很详细的说明。本文想说的是，在纯技术因素外，软件版本号的命名其实更多地体现了各种商业逻辑。

我们来看几个现实的案例：

1）Oracle公司的前身RSI（Relational Software, Inc）公司于1979年发布了数据库产品Oracle V2，至于V1，实际上从未正式发布过。这是因为，当时这家公司的负责人Larry J. Ellison认为客户不会购买第一个版本，所以才玩了这么一个花招。

2）Chrome浏览器后来居上，短时间内就超过了Firefox多年积累下的市场占有率。Chrome是软件行业首个让版本号失去参考意义的产品，因为这家伙三天两天就更新一个版本号，而别人一年也就升一个大版本号。为了“与时俱进”赶超对手，Firefox开始执行快速发布模式，6个星期更新一个大版本。应该说，Firefox通过提升版本号，确实给人耳目一新的感觉。

3）微软公司的Office 2013内部开发版本代号为Office 15，作为消费者，你觉得哪个版本号听起来比较有“新”的感觉呢？

上面都是比较正面的案例，当然了，也会有一些比较令人无语的，例如J2EE 1.5被改名为Java EE 5。我记得第一次安装JDK时，研究了好一阵才明白哪个是个哪个，被绕晕了，因为网上的各种教程不一定是最新的，什么版本号写法都有。

了解了业内知名企业机构的做法，有助于我们制定适合自己的软件版本号命名策略。就企业级软件产品而言，我认为，虽然我们不必像某些个人级App产品那样几个星期就发一个版本，但是我们的产品发布周期也不应太长（一年一个版本挺适中的）。为保持对客户的吸引力，可以适当提升版本号，例如今年是6.0，明年就发布7.0，而不是继续发布6.1，这样从版本号上看起来会“新”和“高级”点。

设想这么一个情景：某位老客户两年前买了你的6.0版本，两年后你要劝说客户升级到6.2版本，这个时候客户可能会潜意识里认为，从6.0到6.2只是很小的变动，没有必要升级；假如你每年提升一个大版本号，两年后已经推出8.0版本，这个时侯让客户升级，至少在数字上会更有说服力。

让客户为你的软件买单，总是需要一个理由的，有人喜欢价格够优惠，有人看中功能够丰富，也有人关注诸如版本号这种信息。我不是想教坏大家，而是想说，既然适当处理一下版本号可以让客户觉得买这个东西更物有所值，那又何乐而不为呢？

写到这里，我突发奇想：也许我该向公司开发提一个需求，将今年的新版产品版本号改为V2014？要真如此的话，那我们就可以在版本号上秒杀所有竞争对手了，仔细想想还真的有些小激动呢（just joking哈）~

其他有用资源：
# Semantic Versioning 一个比较流行的版本命名规范
# What’s In a Version Number, Anyway?  Stack Overflow联合创始人Jeff Atwood写的一篇相关博文