Spring Cloud 终于改了，为什么要用日期来做版本号？
Spring Cloud 终于改了
最近 Spring Cloud 把版本号从 A 到 Z 的伦敦地铁站，改成用日期命名了。
也就是从 Greenwich.SR6, Hoxton.SR9 这样的风格改成了 2020.0.0 的形式。广大人民终于不用为 Spring Cloud 的版本号烦恼了。
Spring Cloud 推广不力，固然有自身复杂的原因，版本号太复杂也是一个坑。
以日期为版本号，即所谓的 Calendar Versioning，可以参考这个网站：
何时使用 CalVer
如果你和很多素不相识的人协同开发某个项目，那么使用一个严谨的版本命名方式是一个合适的选择，恰巧 CalVer 就是选择之一。
该项目是否具有较大或不断变化的范围？
- 大型系统和框架，如 Ubuntu 和 Twisted。
- 没有实际边界的实用工具集合，如 Boltons。
该项目是否对时间敏感？是否有其他的外部变化驱动项目新版本的发布？
- 业务需求，例如 Ubuntu 的支持计划。
- 安全更新，例如 certifi 对证书更新的需求。
- 政治变化，例如 pytz 对时区变化的处理。
如果你对这些问题中的任何一个回答是肯定的，CalVer 都可以成为你项目的有力选择。
但上面这些理由我觉得都不够充分。
在我看来最重要的理由是：以日期为版本号，让依赖库的开发方和下游依赖方达成了默契。
阿里巴巴的实践
Pandora 是阿里巴巴内部的隔离容器。在 14 年时，Pandora 包版本号是这样子的：
- 2_1_0_3 , 2_1_0_4_10-LOG
后面改为 Pandora 版本 + 日期
- 2_2_140825, 2_2_140905
但实际上应用方并不关心 Pandora 的版本，所以改成了现在的风格：
- 2020-04-release-fix , 2020-10-release
好处是：
按时间节点推动升级
电商的业务都是时间为关键节点的，比如 618/双 11。中间件和应用方达成了一个默契：到关键时间点，业务方使用中间件推出的稳定版本，如果出了事故那么就是中间件的锅。不升级，则是业务方自己的锅。
推动升级的阻力变小
当业务方遇到问题时，一看版本号是 1 年多前的，很自然就会想到升级。
依赖提供方要按时间保持更新
维护人员本身要不断发版本证明自己的生命力。下游用户也可以根据时间选择是否要切换到其它的新技术路线上去了。
对于一些总体的依赖，比如公司内部的 maven bom，都建议使用时间做日期。
比如 Spring 2.5.6 版本，大部分开发都知道它是比较旧的依赖，但不会有太大的动力去管。
但是如果你说，这是 12 年前的代码（绝大部分开发还没毕业），那么开发人员就知道很容易会出现不兼容的问题，他自己就知道应该要升级了。
以时间为版本号，既是对用户的承诺，也是对开发者自己的鞭策。
Spring Cloud 终于改了，为什么要用日期来做版本号？
