我“硬刚”mmkv开源库对于版本号的定义赢啦！

我“硬刚”mmkv开源库胜利啦！
前情是这个帖子https://blog.csdn.net/jzlhll123/article/details/139917169

之前项目中将mmkv1.3.4升级到1.3.5或者1.3.6，就从firebase后台上看到crash。

java.lang.UnsatisfiedLinkError: dlopen failed: library “libmmkv.so” not found。

原因它release note说明如下：

导致了我的不少armV7架构手机用户出现了crash。

对于普通程序员而言一般不会去看你的库升级了什么，看到gradle有黄色提醒，而且仅仅是第三位版本号升级，自然就给升级上去了。
结果导致armv7手机开始报错，提示 “libmmkv.so” not found。那么，可能我是第一个发现这个问题的根本原因，于是去mmkv的github的issue看到满屏的抱怨：

经过我的多方研究，将我的研究结果，
附在了其中2个issue中，给出了建议：

于是，腾讯的大佬回复：

Don’t spam everywhere. If armv7 is the issue you can always fork mmkv
and add back armv7 support by yourself. It’s open sourced.
不要到处抱怨，这是开源的，你可以自己去编译。

诶，我有点不能“忍”，紧接着我又友好(ji mang)地回复(ying gang)到：

我还是坚持自己的意见。对于大部分普通程序员而言，一个库是否好用在于它的延续性，
如果对于兼容性存在问题的情况下， 可以将库的版本进行别的版本号区分发布。而不是1.3.4，变成1.3.5。
对于版本号也不是很好的尊重。

于是，还没等我再回复一句，就已经关闭了回复。

hah，让我闭嘴了。

然后，时间过去了2周，看着越来越多的人给他提issue，看来他们终于抗不住了。发布了1.3.7版本：

可以看到，他们吸取了我的建议，后续版本号将定为2.0，而且长期支持1.3.7(当然只是修正bug不再上新功能)，并加了回来armV7和x86的库，我也已经验证库都回来了。

所以，对于这个事情，我胜利了？

真理越辩越明，相信会越来越好。对于国民最牛库之一的mmkv，也希望它越来越好！

附录：

第一位（1）：主版本号。当功能模块有较大的变动，比如增加多个模块或者整体架构发生变化。此版本号由项目决定是否修改。
第二位（2）：子版本号。当功能有一定的增加或变化，比如增加了对权限控制、增加自定义视图等功能。此版本号由项目决定是否修改。
第三位（3）：修订版本号。一般是 Bug 修复或是一些小的变动，要经常发布修订版，时间间隔不限，修复一个严重的bug即可发布一个修订版。此版本号由项目经理决定是否修改。
日期版本号（20201228）：用于记录修改项目的当前日期，每天对项目的修改都需要更改日期版本号。此版本号由开发人员决定是否修改。