当然，这个在这里谈的很多了， 但这里只是说说我们这边用的几种模式， 主要针对发布比较频繁发布的情况，比如两周一次，一个月一次之类的。
【一、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吧
)
{ }排序的实现过程)
