一、组件化早期实践发现的问题

1.组件更迭不规范，大小版本更新不清晰，版本号管理无序

如A组件修改了自身0.0.1版本某个api的内部bug,升级为0.0.2版本
而B组件修改了自身0.0.1版本某个api的名称，升级为0.0.2版本
实际上我们通常认为末尾小版本号的更新表示较小的改动比方说修正bug,
因此A从0.0.1->0.0.2是正确的，而B因为改动过大，正确的做法是进行中间版本号的升级，如0.0.1->0.1.0

2.组件间的依赖没有规范，容易造成组件更新后的未知错误

如B组件0.0.2版本相对0.0.1版本更改了部分API,造成实际依赖B组件0.0.1版本的C组件盲目使用自动更新后的0.0.2版本，造成C组件无法使用

3.项目发布频繁，穿插版本发布，造成组件引用难管理

如开课啦直播上一个版本号为1.13.0,对应使用的A组件为0.0.1
现在进行开课啦直播2.0.0的开发，A组件已经升级为0.1.0支持2.0.0的业务
但是中间突然需要插入开发一个开课啦直播1.14.0版本，此时A组件已经升级为0.1.0版本支持2.0.0的业务，因此需要从A组件0.0.1版本单独拉出一个0.0.2版本支持开课啦1.14.0的开发任务，造成组件版本混乱

二、解决方案

1.版本号规范

1.从开课啦直播2.0版本开始，所有改动的组件版本号从1.0.0开始
2.修改内部逻辑、bug修改，只修改最后一位版本号，如1.0.0->1.0.1
3.改动api、新增功能的改动，与旧版本有明显兼容问题，修改中间版本号,如1.0.0->1.1.0
4.重大调整如整体架构调整、业务重构，修改首位版本号如1.0.0->2.0.0

WX20180515-151911@2x.png

2.依赖规则

1.基于上述原则，我们认为末尾版本号的改动不会影响当前版本的使用。因此可以在允许末尾版本号变动的情况下使用该组件。

如A组件引用B组件1.0.0版本，默认只要是符合1.0.*规则的B组件都能够被正确使用。
在A组件中引用B组件需要使用如下方式：
s.dependency 'XHXKit', '~> 1.0.0'
cocoaPod为我们提供了~>指定方式，它的意思是最后末位允许变化，找符合条件的最大版本。如当前有1.0.0、1.0.1，2.0.0版本，~>1.0.0只会从1.0.0和1.0.1中选择最大的1.0.1版本使用

2.所有依赖都需要指定自己依赖的的组件版本

通过上述指定版本方式，如A组件依赖BCD三个组件，都需要为BCD指定具体版本保证当前A组件在当前依赖下绝对可用，如下：

s.dependency 'B', '~> 1.0.0'
s.dependency 'C', '~> 1.2.0'
s.dependency 'D', '~> 1.1.0'

3.主工程指定自身依赖的业务模块组件版本，不需要引入或指定基础组件的版本

如主工程依赖组件A，组件依赖BCD，主工程只需要指定组件A的版本，不需要引入或指定BCD的版本，让组件自己的依赖来决定
这里，当出现多个子依赖时，cocoaPod会默认寻找最低的那个版本
如：A依赖C的1.1.0，B依赖C的1.2.0版本，主工程依赖AB，这时cocoapod会选择C的1.1.0版本（这里就会出现pod报错或者B版本的不兼容问题，需要A或B对C进行升级兼容，根据我们的版本号规范一般在编译时就能发现问题）

WX20180515-153113@2x.png

3.版本穿插发布的组件更新原则

正常情形下的组件版本更新，需要保持高版本对低版本的兼容。项目流程上讲，中间穿插版本属于特殊情况。
如正在开发开课啦直播2.0，需要从1.0的基础上紧急发布一个1.1版本。
此时1.0版本依赖于1.0.0版本的A组件，2.0版本依赖于1.1.0版本的A组件。
此时的1.1.0版本A组件很可能已经产生了1.0版本不需要的功能点。
为了保证1.1版本项目的稳定性，此时对1.0.0版本的组件更新需要打破我们的组件版本号原则，只保持对末位版本号的更新。

WX20180515-154537@2x.png

三、总结

1.开课啦直播2.0版本用到的组件，更新组件版本号从1.0.0起
2.组件版本号遵循版本号管理原则（架构调整.改动API.修bug）
3.组件通过~>指定依赖组件的版本，主工程指定业务模块组件版本号，不依赖基础组件
4.穿插版本情况下，只保持对组件末位版本号的更新
5.组件版本变化需要尽可能的保持对旧API的兼容，可以废弃、增加，尽量不修改API。