当然，这个在 谈的很多了， 但这里只是说说我们这边用的几种模式， 主要针对发布比较频繁发布的情况，比如两周一次，一个月一次之类的。

 

【一、major.minor】

比如1.0, 1.2, 2.5, 3.0等等。 major是主要版本号，major相同，minor不同的版本，是后相兼容的 - 也就是说不会有schema change（如果读文件的话），也不会有breaking api（如果暴露api的话）。

当然，你觉得一个major不够用，完全可以扩展为major.major.minor， 如果你在乎后向兼容，这个的确蛮好用的。

 

major.minor的问题在于如何比较两个版本哪个更新：比如:5.8和5.12， 数字上5.8 > 5.12， 而可能发布者的用意是5.12 > 5.8， 那么5.8是不是5.08更合适； 总之，有点混淆在里面了。

当然，只要事先安排好，还是可以做的很好的，比如定义minor都是两位的，那么就不会有5.8： 要么5.80，要么5.08。 超过99的版本，必须升major。

 

【二、递增的整数】

这个在我们以前的产品里用过，貌似是没有上面那个问题了。

但是用户看到这些愚蠢的版本号：比如137, 55, 33，迷茫之外除了骂人真的不能期望他们再做些别的了：这TM都什么意思？？？

 

【三、日期】

最好是按照ISO日期格式： 20121205， 这个好处是除了表示日期之外，按整数看还是递增的，比较好用。

• 比如用户看到一个版本：20121205，就知道这是2012年12月5号发布的；
• 比如我说所有比20121205老的版本都不支持邮件通知这个功能，大家也很清楚这是什么意思。

用日期的问题是如果你一天有多个版本发布（疯了？）就没法表示了，一个简单的方法是用symbolic link:

20121205 -> 20121205-1

 

所以，如果你的软件要在一定时间内提供后向支持，用major.minor吧； 如果不要，那么请用ISO date吧