Spring Cloud终于改了
最近Spring Cloud把版本号从A到Z的伦敦地铁站，改为以日期命名了。
也就是从 Greenwich.SR6, Hoxton.SR9 这样子的风格改为 2020.0.0。广大人民终于不用为spring cloud的版本号烦恼了。Spring Cloud推广不力，固然有自身复杂的原因，版本号太复杂也是一个坑。
以日期为版本号，即所谓的Calendar Versioning，可以参考这个网站：
艿艿：Spring Data 也开始使用日期作为版本号！！！！
下面是calver网站的说明。
何时使用 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年之前的代码（绝大部分开发还没毕业），那么开发人员就知道很容易会出现不兼容的问题，他自己就知道应该要升级了。
以时间为版本号，既是对用户的承诺，也是对开发者自己的鞭策。
后记
Java领域的微服务虽然不能说尘埃落定，但目前是Spring Boot一家独大。在这5年间有很多故事，我们也有很多实践。立一个flag，希望能写一系列文章记录下来。
