开发过程
最初想直接在 mybatis-provider 项目中添加一个 config 包来实现这些功能，也确实这么做的，后来想要拆出来时发现用到了 mybatis-provider 中的代码，又不想拆了，但是最后为了能直接支持 Spring，又不想让 mybatis-provider 中出现 Spring 依赖，终于拆了出来。
在开发 1.0.0 的过程中，耗时最多的地方是版本配置的实现，一开始考虑到版本配置文件可以出现在任何地方，因此需要扫描所有位置来找符合规范的配置文件，然后从配置文件中挑选指定的一个配置文件使用，在1.0.0版本中只会使用指定的这一个版本，如果没有指定，默认会使用最新版本的这一个配置文件。
想要扫描所有位置比想象中的复杂很多，常见的各种工具中，大部分都是指定扫描包，根据接口或者注解获取所有实现类的方法，获取资源文件的很少见。当同一个版本的配置文件出现在多个不同的 jar 包时，到底选择哪一个才合适！这个方案扫描范围太广，肯定会有性能问题，而且扫描到这么多文件后的选择也是一个问题，这些问题导致开发进度停了很久。
最后觉得再拖下去也没结果，既然版本配置是给组件开发人员使用的，严格的限制不会带来使用上的问题，规则简单一些也方便使用，然后就确定了方案：从当前配置类所在包下查找版本配置文件。
方案确定后，后续一切进展很快，集成 Spring 也很顺利，很快就在 2022-6-29 号发布了 1.0.0 版本。
1.1.0 主要变化有哪些？
1.0.0 发布后，自我感觉是，先让自己能用上，等后续有时间的时候再补充个简单文档就够了，又不会有其他人会用，不用那么麻烦。
没想到没隔多久就有了这个小系列，写作梳理的过程会重新审视整个项目的设计，有一些不完善的地方就会自己冒出来，在画下图版本配置读取值的逻辑时产生了变化。原来的方案是如果指定了 2.0 版本，其他版本根本不去读，只用指定的这一个。如果在 4.0 高版本中增加了新的属性，在指定读取的 2.0 配置中找不到时，此时程序是否会出错？新的配置总会有变化，大概率会新增，这个问题也不难处理，就是把其他版本的配置作为默认配置，当前的 Properties 找不到时，就去默认配置中找，默认配置根据版本的顺序形成了一个链式结构，和 ConfigHelper.CONFIGS 是一样的原理，一个是向上递归，一个是循环迭代，这样的设计看起来更完美一些，所以在写 （四）版本配置实现 的同时把代码一起改了。
变成这种结构后，如果程序一定使用最新版本配置时，版本配置中的内容可以直接按照增量的方式去维护，和前一个版本相同的内容不用重复配置，增量配置更容易看出配置参数的变化。
但是，如果支持可选版本，还是在每个配置文件中写全吧，否则指定 2.0 时，大多数情况想要的是 2.0 和 1.0 合并后的配置。增量配置时只使用 2.0 变化的部分，下一个获取的是 4.0 不是 1.0，这会让 1.0 中的配置存在被 4.0,3.0 覆盖的风险，如果是全量的配置，读取 4.0 时只有新增的配置有效，和 2.0 相同的配置不会生效。
1.1.0 发布
在写作本文的同时，在 GitHub 代码仓库创建了 1.1.0 的 Tag，自动触发了 Action 中的发布操作，1.1.0 已经正式发布。
[INFO] * Upload of locally staged artifacts finished.
[INFO] * Closing staging repository with ID "iomybatis-1038".
Waiting for operation to complete...
..........
[INFO] Remote staged 1 repositories, finished with success.
[INFO] Remote staging repositories are being released...
Waiting for operation to complete...
......
[INFO] Remote staging repositories released.
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 01:36 min
[INFO] Finished at: 2022-07-09T04:53:45Z
[INFO] ------------------------------------------------------------------------
自从用了 GitHub Action，发版再也不是一个艰难的运气活了。
参考：通过 GitHub Actions 自动发布项目到 Maven 中央仓库
