开篇废话
MeiliSearch 可能是我目前 20 年人生中碰到的最多 update break 的软件。
作为一个 Arch Linux 用户，每个月 -Syyu 是必然的，不过 Meilisearch 因为更新了数据需要重新导入之类的原因咕了好久都没更 春节闲的蛋疼的时候终于来更了。
由于升级体验实在过于糟糕，所以我没打算直接在原来的初体验文直接更新，而另开了个新帖子。
另外本文是个思路，大概就讲了更新软件该做些什么工作。
正文
首先我们大概有以下两个思路去适配新版本的 MeiliSearch：
- 运行出 bug 了再对着文档搞
- 浏览最近更改，本地适配完毕再来更新线上环境
我选择两个一起做
另外还要看看时间成本，如果更改过于多，不如当之前没用过，对着接口（文档）全部重构，就懒得看更新日志了。
浏览更改
想到上次用 MeiliSearch 还是在半年前，大概 v0.21 版本，我们顺着 MeiliSearch 的 GitHub Release 开始找
由于连 CHANGELOG.md 都跑路了所以才看 Release note 的
Github release 顺着找，作者们也知道自己的软件很多 Breaking changes 大概浏览下
- v0.21.0
- filters -> filter 然后语法有点变化 （从这个版本有能用的 web 页面了）
- v0.22.0
- 大概是一些排序之类的语法变化，好像有用到
- v0.24.0
- 看上去是 errorcode 之类的更改，不是客户端用官方 sdk 应该不影响
- v0.25.0
- API Key management （之前生成key鉴权的时候有用到）然后好像多了个任务列表的接口
（rc 为候选版本，一般不需要看，在正式版本里面应该是有重复提到的）
心理有数后就可以开始更新了。
主程序更新
首先导出数据
MeiliSearch 各大版本的数据（data.ms）是不通用的，我们需要先 dump 出所有数据，然后在新版本的 MeiliSearch 再导入数据
简单来说就是 /var/lib/meilisearch/ 里面（文件路径自己定位啦 我这是这个）的 data.ms 是包括索引等其它东西的，并不是纯数据，我们需要 dump 出某一时刻的版本出来。
在这阶段我是建议不要运行依赖 MeiliSearch 的程序了，等下出现数据不同步情况就gg了。
curl -X POST 'http://127.0.0.1:7700/dumps'
{
"uid": "20210212-114515191"
}
稍等片刻，大概就 dump 完成了
查看进度：
curl -X GET 'http://127.0.0.1:7700/dumps/:uid/status'
{
"status": "done"
}
然后数据会在数据文件夹/dumps 里面
然后更新 MeiliSearch 本体（自己从 GitHub Releases 里面下）
# 更新命令 （自己想）
cd /var/lib/meilisearch/
mv data.ms data.ms.bak # 备份原来的，导入成功后可以删掉
meilisearch --import-dump dumps/uid.dump
然后等导入完成
太久没更新的话（由于跨的版本很大），甚至需要一个中间版本来更新，所以我们先把主程序更新到 v0.24，然后再更新到 v0.25.2 （截止目前的最新版本）
更新完成后，我们对着之前收集的更新日志处理下，比如鉴权模块被重写了，那就重新生成 key，排序方式似乎也被重置了，那就重新 post。
使用的项目更新
我使用 MeiliSearch 的项目是 @zaobao_bot ，在主程序更新后对应客户端 sdk 也要更新
yarn add meilisearch
更新到最新版本，然后再对着文档搞，一般来说就是哪里报错修哪里，不过我们浏览过更改的可以提前先改好一点。
总结
在这之前都没有软件更新能让我折腾上一天的，这样舍弃兼容性的大更改可以甩掉很多包裹，不过会对依赖这个软件的项目或多或少有影响，也算是理解 RHEL 这样给上世纪包的企业级做法了。
作为开发来说，做功能之前还是弄个路线图之类的规划好来，而不是随心所欲随便加/删/改，在不得不更改的时候标出 Breaking change 然后提醒使用者去配合改大概就好了（仁至义尽，已经通知到就好）。
作为程序依赖的开发者，对于依赖要跟踪其频道，在更新前留意下更新日志比较稳妥点，直接跑然后报错了再改也 ok。
然后 docker NixOS 的优势就出现了，线上环境不会因为版本问题而炸，可能方便多了。
完