你肯定注意到了，Firefox的版本号跟坐了火箭一样，几年前还是3.x，没多久就蹦到57，现在都100多。而隔壁Chrome呢，稳定版从1.0到现在的120，虽然也在涨，但步调看起来就“稳重”些。这背后不是随便拍脑袋决定的，纯纯是两种版本发布哲学的对撞：一个把版本号当营销工具，一个把版本号当工程承诺。说白了，版本号不只是给开发者看的，它还是给用户、给插件生态、给企业IT部门的一个信号，信号发错了，麻烦就来了。
先聊聊Chrome的“日历版本”大法 —— 每六周一次大版本更新，版本号和日期挂钩。其实Google自己也承认，他们内部早就放弃了语义化版本的意义，每次就是加个数字，因为没人care你的minor修了啥，用户只知道“浏览器要更新了”。这种策略让Chrome的迭代节奏稳定，用户习惯养成，网站兼容性测试也只要盯准一个数字。但代价是breaking change经常悄悄混进去，你都不知道哪个minor更新让你的老插件瞬间变废铁。很多企业为了省事，直接锁死一个年份版本，打死不升。
反观Firefox，当年的3.0时代确实太保守，功能憋太久，被IE和Chrome夹击得喘不过气。后来Mozilla学了Chrome的快速发布，但没学到精髓 —— 版本号还是语义化的底子，但频率突然加快，结果就是版本号语义彻底失效。用户上一秒用着35，下一秒变38，实际界面变化却小得可怜。插件开发者惨了，每次都得跟着改兼容，很多好用的扩展直接弃坑。我记得当时有个老用户说：“我不管你是3还是57，我只想让我那个下载图片的扩展继续用。”这话特别戳心。
那到底哪种策略好？我的观点是，都没说到根上。问题根本不在版本号格式，而在于你发布的时候，有没有把“可预期的兼容性”作为第一原则。Chrome的日历版本胜在节奏可预期，但破坏了语义承诺；Firefox的快速迭代为了追分，同时丢了节奏和语义。如果你在做一个底层库或者平台，比如.NET或者Python，那语义化版本还是王道，因为你的用户是程序员，人家真靠版本号判断风险。如果你做的是Chrome这种终端消费品，那干脆就老老实实用年份版本号，别搞什么minor patch的虚头巴脑。最怕的就是像firefox这种卡在中间，既想表达技术进度，又想讨好普通用户，最后两边不讨好。
另外我还发现一个现象：版本号越高的软件，用户越容易产生“是不是很复杂”的焦虑。你去软件下载站看评论，总有人说“我还在用老版本，不敢升级”。这其实就是版本发布策略的锅，每次更新都没有给用户一个非要升级不可的理由，反而用无意义的数字变化制造疲惫感。真正漂亮的发布策略，是让用户忽略版本号的存在，比如微信，你已经不记得它是7.0还是8.0，因为每次更新都在背后悄悄做完了。所以别再纠结一个叫“版本号”的玩意儿了，你的用户只关心一件事：更新完，我的东西还能不能正常用。