在我们的系统中，架构共通依赖相关工程主要有两类：
1、微服务根依赖，主要由技术架构组维护，用于对系统整体的依赖进行约束，避免业务微服务出现不稳定版本的依赖或者兼容性问题，统一业务微服务工程的编译方式
2、架构共通包，主要由技术架构组维护，用于规范化全系统的响应体、认证流程、日志记载、异常处理等等
版本号升级场景：
A 系统使用技术框架发生变化，例如：Spring Boot、Spring Cloud等依赖发生大版本变更，或者系统整体架构发生大调整
B 系统使用的Spring Boot、Spring Cloud小版本升级，注意：在升级此版本时务必慎重，架构人员在本地升级并测试各类工程
能够正常启动和工作后再提交，以免引起大范围的问题
C 系统中业务开发普遍需要的依赖发生变化，或者build等Maven标签配置变化的场合
D 版本升级过程中发生问题进行修复
版本号升级方式：
工程起始版本为1.0.0，
A 在版本升级场景A的场合，升级第一位版本号，例如：2.0.0
B 在版本升级场景B、C的场合，升级第二位版本号，例如：1.1.0，
C 当版本升级场景D的场合，升级第三位版本号，例如：1.1.1
注意：
1、根依赖定义作为所有微服务的架构约束，不进行分支管理，通过版本号即可满足所有应用场景
2、原则上所有业务微服务都应该依赖最新版本的根依赖，以使用最新特性和规避原有问题，对于从产品化版本中拉出的项目分支来说，可以出现不同项目依赖版本不同的根依赖
版本号升级场景：
A 系统使用技术框架发生重大变化，或者系统整体架构发生大调整，或者架构共通包重新梳理，或者系统架构规范标准调整等
B 系统依赖的库发生小版本升级，或者架构共通包功能特性有较大变化（参数变化、功能变化、大幅度优化等）
C 架构共通包功能发生较微小调整（非参数变化调整、功能微调、小幅度优化）
D 架构共通包Bug修复
版本号升级方式：
工程起始版本为1.0.0
A 在版本升级场景A的场合，升级第一位版本号，例如：2.0.0
B 在版本升级场景B、C的场合，升级第二位版本号，例如：1.1.0
C 当版本升级场景D的场合，升级第三位版本号，例如：1.1.1
注意：
1、架构共通包的功能特性定义是对系统规范标准的落实，也是对部分外部依赖的应用优化，不进行分支管理，通过版本号即可满足所有应用场景
2、原则上版本越高问题越少，功能特性越丰富，业务微服务可根据需要引入
