阅读全文

⭐⭐⭐ Spring Boot 项目实战	⭐⭐⭐ Spring Cloud 项目实战
《Dubbo 实现原理与源码解析 —— 精品合集》	《Netty 实现原理与源码解析 —— 精品合集》
《Spring 实现原理与源码解析 —— 精品合集》	《MyBatis 实现原理与源码解析 —— 精品合集》
《Spring MVC 实现原理与源码解析 —— 精品合集》	《数据库实体设计合集》
《Spring Boot 实现原理与源码解析 —— 精品合集》	《Java 面试题 + Java 学习指南》

摘要: 原创出处 横云断岭 「横云断岭」欢迎转载，保留摘要，谢谢！

• Spring Cloud终于改了
• 何时使用 CalVer
• 阿里巴巴的实践
• 后记

---

🙂🙂🙂关注**微信公众号：【芋道源码】**有福利：

1. RocketMQ / MyCAT / Sharding-JDBC 所有源码分析文章列表
2. RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址
3. 您对于源码的疑问每条留言都将得到认真回复。甚至不知道如何读源码也可以请教噢。
4. 新的源码解析文章实时收到通知。每周更新一篇左右。
5. 认真的源码交流微信群。

---

Spring Cloud终于改了

最近Spring Cloud把版本号从A到Z的伦敦地铁站，改为以日期命令了。

• https://spring.io/blog/2020/04/17/spring-cloud-2020-0-0-m1-released

也就是从 Greenwich.SR6, Hoxton.SR9 这样子的风格改为 2020.0.0。广大人民终于不用为spring cloud的版本号烦恼了。Spring Cloud推广不力，固然有自身复杂的原因，版本号太复杂也是一个坑。

以日期为版本号，即所谓的Calendar Versioning，可以参考这个网站：

• https://calver.org/overview_zhcn.html

下面是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

好处是：

1. 按时间节点推动升级

   电商的业务都是时间为关键节点的，比如 618/双11。中间件和应用方达成了一个默契：到关键时间点，业务方使用中间件推出的稳定版本，如果出了事故那么就是中间件的锅。不升级，则是业务方自己的锅。

2. 推动升级的阻力变小

   当业务方遇到问题时，很多时候是不业务方一看它的版本号是1年多前的，很自然它就会升级了。

3. 依赖提供方要按时间保持更新

   维护人员本身要不断发版本证明自己的生命力。下游用户也可以根据时间选择是否要切换到其它的新技术路线上去了。

对于一些总体的依赖，比如公司内部的maven bom，都建议使用时间做日期。

比如spring 2.5.6版本，大部分开发都知道它是比较旧的依赖了，但不会有太大的动力去管。 但是如果你说，这是12年之前的代码（绝大部分开发还没毕业），那么开发人员就知道很容易会出现不兼容的问题，他自己就知道应该要升级了。

以时间为版本号，既是对用户的承诺，也是对开发者自己的鞭策。

后记

Java领域的微服务虽然不能说尘埃落定，但目前是Spring Boot一家独大。在这5年间有很多故事，我们也有很多实践。立一个flag，希望能写一系列文章记录下来。