这是一个旧的 issue，被我从 Hover 项目 issue 中移植过来，留档保存。
2017 年由 杨帆 提出
将本地化文件做成 pod 的过程中碰到这样的问题。
当前 Hover、Album、Share 均依赖了某一个版本的 Hover-I18n（即本地化文件做成的 pod），当 Hover-18n 更新时，可能只需要更新前三者中的一个而不是全部。例如，某一个新增需求只增加了 Hover 项目中的文案，Album 与 Share 文案无需变动，这时
- 可以同步更新 Hover、Album、Share Podfile 中 Hover-I18n 的版本号，但 Album、Share 中的 Podfile 其实是不用修改的。
- 可以只更新 Hover Podfile 中 Hover-I18n 的版本号，但由于 Hover、Album 依赖了不同版本但 Hover-I18n，无法 pod install 成功。
请问有什么 trick 的办法可以巧妙的解决这一问题？
From MJXin：
两种方式：
- 之前我们提到过的语义化版本号可以用起来。
- pod 引用的时候不要写死版本号，而只引用到主版本号
- 每次库个更新的时候遵循语义化版本号规定，当修改不涉及接口的时候不修改主版本号。一旦涉及接口修改，更新主版本号，并且所有引用的模块同步更新
- 直接不写版本号（对于一些轻量级开发完后不更改的库可以如此处理）
From GeorgeWu：
语义化版本号是指 Semantic Versioning?
From MJXin：
近期小视频和默认滤镜这块频繁动了几个库，以前写死版本号的方式确实造成了很大困扰。
- 对外，我们确实可以使用写死版本号的方式引用第三方库，在已有版本满足功能的情况下，这可以预防对方有我们期望之外的其他修改导致对程序产生不必要的影响。
- 对内，因为库由我们自行开发，所有行为已知并且会经常改动，写死版本号反而会对开发造成一定困扰
From yangfan：
我总结下这个结论, 并关闭这个 issue:
- 我们需要使用 semantic versioing 来避免这样的问题;
- 我们当前暂时不拆多个库，主要是用来权衡，多个库的维护成本，外包公司是否方便，和我们灵活性收益的代价.
如果有进一步讨论，我们再 reopen