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

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

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

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

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写的一篇相关博文